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Введение 

Бог даровал человеку жажду духовного мира, эстетических ощущений, 
безопасности, справедливости и свободы, которые нельзя обеспечить простым про¬ 
мышленным производством. Но производство позволяет уйти от постоянной борьбы 
с нищетой и приблизиться к всеобщему благосостоянию, высвободить дополни¬ 
тельное время для духовного и эстетического развития, а также переложить часть 
проблем на специально создаваемые для этой цели институты религии, закона и 
охраны свободы. 


Харлан Миллс 
(DPMA and Human Productivity) 

Как профессионалы в вычислительной технике, мы стремимся создавать 
полезные и работающие системы; а как программисты, мы вынуждены со¬ 
здавать сложные системы в условиях сильно ограниченных ресурсов. В по¬ 
следние несколько лет объектно-ориентированная технология развивалась в 
различных областях вычислительной техники как средство решения проблем, 
связанных со сложностью создаваемых систем. Объектный подход доказал 
свою эффективность и универсальность. 

Цели 

Так как опыт применения объектно-ориентированного проектирования 
относительно невелик, об эффективном использовании элементов объектного 
подхода, как дисциплине, говорить еще рано. Данная книга — первое прак¬ 
тическое руководство по созданию объектно-ориентированных систем. Автор 
ставил перед собой следующие цели: 

* Разъяснить фундаментальные концепции объектного подхода. 

* Помочь овладеть терминологией и методами объектно-ориентированного 
проектирования. 

* Научить применять на практике объектно-ориентированное проектирова¬ 
ние, используя языки программирования Smalltalk, Object Pascal, C++, 
CLOS и Ada. 

Все концепции, рассмотренные в данной книге, имеют глубокую теоре¬ 
тическую основу; тем не менее это — книга для практического 
использования, в которой обсуждаются проблемы создания больших 
промышленных программных систем. 

К читателю 

Книга рассчитана на профессионалов и студентов, начинающих изучать 
данные вопросы. 

* Программисты-практики найдут подходы к эффективному использованию 
объектных и объектно-ориентированных языков программирования при ре¬ 
шении практических задач. 

* Аналитики и системные проектировщики найдут рекомендации по перехо¬ 
ду от исходных требований к их реализации с помощью методологии объ¬ 
ектно-ориентированного проектирования, научатся отличать «хорошие» 
проекты от «плохих» и производить изменения, вызванные внешними при¬ 
чинами, а также, что наиболее существенно, найдут новые подходы к ре¬ 
ализации сложных систем. 






* Руководители программных проектов могут ознакомиться с приемами рас¬ 
пределения ресурсов при групповой разработке программ и способами пре¬ 
одоления трудностей, связанных с созданием сложных программных 
систем. 

* Разработчики и пользователи инструментальных средств найдут подробную 
информацию по системе обозначений, применяемой при документировании 
процесса объектно-ориентированного проектирования. 

* Студенты получат инструкции, позволяющие сделать первые шаги в тео¬ 
рии и практике разработки сложных программных систем. 

Книгу можно использовать как учебное пособие в вузах и для самосто¬ 
ятельного изучения предмета. Книга состоит из трех основных частей: кон¬ 
цепции, методология и применения. 

Концепции 

В части I рассмотрены вопросы, связанные со сложностью программных 
систем и видами проявления этой сложности. Объектный подход предлагает¬ 
ся в качестве средства решения проблемы сложности. Подробно рассматрива¬ 
ются основные элементы объектного подхода: абстракции, ограничение досту¬ 
па, модульность, иерархия, типирование, параллелизм и устойчивость. 
Определяются такие понятия, как класс и объект. Поскольку идентификация 
классов и объектов является ключевым моментом в объектно-ориентирован¬ 
ном проектировании, в книге уделено достаточное внимание изучению при¬ 
роды классификации. Анализируются, в частности, подходы к классификации 
в таких областях знаний, как биология, лингвистика и психология; затем 
эти подходы применяются к программным системам с использованием мето¬ 
дов анализа предметной области и концептуального моделирования. 

Методология 

В части II описана методология разработки сложных систем на основе 
объектного подхода, названного объектно-ориентированным проектированием 
OOD (object-oriented design). Представлена система графических обозначений 
для документирования процесса OOD, в частности особенности отдельных 
этапов жизненного цикла программных систем и управление процессом про¬ 
ектирования. 

Применения 

В части III рассмотрены пять оригинальных примеров использования 
методологии OOD в различных предметных областях. Эти примеры представ¬ 
ляют основные разновидности сложных проблем, с которыми сталкиваются 
разработчики программных средств на практике. Показать то, как отдельные 
принципы реализуются в практических задачах, не сложно, но гораздо важ¬ 
нее показать, как объектный подход помогает решать проблемы сложности в 
больших системах. Это позволяет сфокусировать внимание на способах по¬ 
строения действительно полезных систем, решающих актуальные задачи. По¬ 
скольку выбранные предметные области знакомы не для всех читателей, 
рассмотрение каждого примера начинается с краткого обзора его особенно¬ 
стей (например, структуры базы данных или архитектуры типа «классной 
доски»). Автор показывает с помощью примеров, как при объектно- 
ориентированном проектировании могут быть использованы различные 
объектные и объектно-ориентированные языки программирования: Smalltalk, 
Object Pascal, C++, CLOS и Ada. Разработка программных систем редко 
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выполняется по методу поваренной книги, поэтому особо выделен последова¬ 
тельный итерактивный процесс создания системы с множеством четко обоз¬ 
наченных критериев и глубоко проработанных подходов. 

Дополнительная информация 

Все разделы книги содержат необходимый дополнительный материал. В 
большинстве глав специально выделена справочная информация по наиболее 
важным вопросам, например механизм реализации методов в различных 
объектно-ориентированных языках программирования. В книгу включено 
приложение, в котором приведены сравнительные данные по используемым 
объектным и объектно-ориентированным языкам и основные характеристики 
языков программирования. 

Для читателей, не владеющих используемыми в практических примерах 
языками, приведены основные конструкции этих языков и соответствующие 
примеры программ. Книга содержит толковый словарь по наиболее употреби¬ 
тельным терминам и понятиям, а также обширную библиографию. Примеры 
программ для гл. 8 — 12 предоставлены издателем. 

Работа с книгой 

Книга предназначена для чтения «от корки до корки», а не по частям. 
Если вы хотите глубоко понять принципы объектного подхода или четко ус¬ 
воить процедуры OOD, следует начать чтение гл. 1 и продолжать далее по 
порядку. Если вас в большей степени интересуют особенности процесса OOD 
и его документирование, можно начать с гл. 5, 6. Гл. 7 особенно полезна 
для руководителей программных проектов, использующих объектную методо¬ 
логию. Для тех, кто интересуется примерами практического применения 
OOD в конкретной предметной области, предназначены гл. 8 — 12. 

Благодарности 
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Часть I 


КОНЦЕПЦИИ 

Сэр Исаак Ньютон однажды признался своим друзьям, 
что хоть он и открыл закон гравитации, но не знает 
механизма его работы. 


Лили Томлин (Lily Tomlin) 
The Search for Signs of Intelligent Life in the Universe 

Глава 1 
Сложность 

Врач, инженер-строитель и программист спорили о том, чья профессия 
древнее. Врач заметил: «В Библии сказано, что Бог сотворил Еву из ребра 
Адама. Такая операция может быть проведена только хирургом, поэтому я 
по праву могу утверждать, что моя профессия самая древняя в мире». Тут 
вмешался строитель и сказал: «Но еще раньше Бог сотворил небо и землю 
из хаоса. Это первое и, несомненно, наиболее выдающееся применение 
строительной инженерии. Поэтому, дорогой доктор, Вы неправы. Моя 
профессия самая древняя в мире*. Программист при этих словах откинулся 
в кресле, загадочно улыбнулся и произнес: «Да, но кто, как rm думаете, 
сотворил хаос?» 

1.1. СЛОЖНОСТЬ, ПРИСУЩАЯ ПРОГРАММНОМУ 
ОБЕСПЕЧЕНИЮ 

Простые и сложные программные системы 

«Умирающая» звезда в предверии коллапса, ребенок, который учится 
читать, клетки крови, атакующие вирус, — все это объекты физического 
мира, обладающие очень большой степенью сложности. Программы для ЭВМ 
могут также содержать элементы, однако их сложность совершенно другая. 
Брукс [1 ] пишет: «Энштейн утверждал, что должно существовать простое 
объяснение всех природных процессов, так как Бог не капризен и при нем 
невозможен произвол. Вера в это не может утешить программиста: 
сложность создаваемых им программ целиком зависит от него самого». 

Очевидно, не все программные системы являются сложными. 
Существует много программ, задуманных, разработанных, сопровождаемых и 
используемых одним и тем же человеком. Обычно это начинающий 
программист или профессионал, работающий в отрыве от коллег; но о таких 
программах все быстро забывают и не о них идет сейчас речь. Мы не 
хотим сказать, что все такие системы плохо сделаны, или тем более 
усомниться в квалификации их создателей. Но такие системы, как правило, 
имеют очень ограниченную область применения и короткое время жизни. 
Обычно их предпочитают заменить новым программным обеспечением, чем 
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постоянно пытаться переделывать или расширять их функциональные 
возможности. Разрабатывать подобные прикладные пакеты скорее 
утомительно, чем сложно, и мы мало заинтересованы в изучении того, как 
это делать. 

Зато нас больше интересует проблема разработки того, что я буду 
называть индустриально организованными программными продуктами. Они 
применяются для решения самых разных задач, таких, например, как 
системы с обратной связью, которые контролируют ход определенного 
физического процесса и для которых критическими параметрами являются 
время обработки и свободное пространство памяти; задачи поддержания 
целостности больших объемов информации при обеспечении к ним 
параллельного доступа различных пользователей; системы управления и 
контроля за реальными процессами (линии воздушного или 
железнодорожного сообщения). Системы такого типа обычно имеют большое 
время жизни и обслуживают большое количество пользователей, результат 
работы которых во многом зависит от нормального функционирования 
предложенных программных средств. Индустриально организованное 
программное обеспечение помогает решать задачи моделирования таких 
сложных процессов, как планирование оптических экспериментов и 
имитация определенных сторон человеческого мышления. Существенной 
чертой индустриально организованных программных средств является их 
больщая сложность: практически невозможно охватить все тонкости системы 
одним разработчиком. Грубо говоря, сложность таких систем превышает 
возможности человеческого интеллекта. Увы, но сложность, о которой мы 
говорим, является, по-видимому, необходимым свойством всех больших 
программных систем. Под необходимостью мы имеем в виду следующее: 
можно создать эту сложность, но нельзя придумать так, чтобы обойтись без 
нее. 

Конечно, среди нас всегда есть гении, люди экстраординарных 
возможностей, которые в одиночку смогут сделать работу за группу 
обычных людей-разработчиков и добиться в своей области успеха, 
сравнимого с достижениями Леонардо да Винчи. Такие люди нам нужны 
как архитекторы систем, т.е. те, кто изобретает новые механизмы, которыми 
можно пользоваться как базовыми при разработке других систем и решении 
других задач. Однако, как замечает Питерс: «В мире очень мало гениев. И 
не надо думать, будто в среде инженеров-программистов их пропорция 
слишком велика» [2 ]. Несмотря на то что все мы чуточку гениальны, в 
области индустриально организованного программирования нельзя постоянно 
полагаться на божественное вдохновение, которое обязательно поможет нам. 
Поэтому мы должны прежде всего рассмотреть уже известные способы 
конструирования сложных систем. Для лучшего понимания того, с чем мы 
собираемся иметь дело, сначала ответим на вопрос: почему сложность 
присуща всем большим программным системам? 

Почему программному обеспечению присуща сложность? 

Как говорит Брукс: «Сложность программного обеспечения — отнюдь не 
случайное его свойство, скорее необходимое» [3]. Его сложность 
определяется четырьмя основными причинами: сложностью проблемы, 
сложностью управления процессом разработки, сложностью обеспечения 
гибкости конечного программного продукта и сложностью описания 
поведения отдельных подсистем. 
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Сложность проблемы. Проблемы, которые мы пытаемся решить с 
помощью разрабатываемого программного обеспечения, часто неизбежно 
содержат сложные элементы, к которым предъявляется множество 
различных, нередко противоположных требований. Рассмотрим требования к 
электронной системе самолета с несколькими двигателями, к телефонной 
коммутаторной системе или к автономному роботу. Довольно трудно даже в 
общих чертах понять, как работает данная система, но прибавьте к этому 
все (часто неявные) дополнительные требования, такие, как удобство, 
производительность, цена, выживаемость и надежность! Эта высокая степень 
сложности задачи и порождает ту сложность программного продукта, о 
которой пишет Брукс. Внешняя сложность обычно возникает из-за 
«несоответствия импедансов», которое существует между пользователями 
системы и ее разработчиками: пользователи обычно с трудом могут внятно 
объяснить разработчикам, что на самом деле нужно сделать. Бывают случаи, 
когда пользователь лишь смутно представляет, что ему нужно от будущей 
программной системы. Это в основном происходит не из-за ошибок с той 
или иной стороны, просто каждая из групп является экспертом лишь в 
своей области и ей недостает знаний в области партнера. У пользователей и 
разработчиков разные взгляды на сущность проблемы и они делают 
различные выводы о возможных путях ее решения. На самом деле, даже 
если пользователь точно знает, что ему нужно, мы с трудом можем 
однозначно зафиксировать все его требования. Обычно они отражены в 
больших по объему текстах, слегка «разбавленных» немногими рисунками. 
Такие документы трудно поддаются пониманию, они открыты для различных 
интерпретаций и часто содержат элементы, относящиеся скорее к дизайну, 



Задачей разработчиков программного обеспечения является создание 
иллюзии простоты. 
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Дополнительная сложность обусловливается изменением требований к 
программной системе уже в процессе разработки в основном из-за того, что 
само существование проекта программной системы часто изменяет проблему. 
Рассмотрение первых результатов — схем, прототипов — и затем 
использование системы уже после того, как она разработана и установлена, 
заставляют пользователей самим лучше понять и отчетливей сформулировать 
то, что им действительно нужно. В то же время этот процесс повышает 
квалификацию разработчиков в области, связанной с решением самой 
проблемы, и позволяет им задавать более осмысленные вопросы, касающиеся 
поведения системы. 

Большая программная система — объект капиталовложений, и мы не 
можем себе позволить создавать ее заново каждый раз при изменении 
требований к ней. Поэтому, хотим мы этого или нет, большие системы 
имеют тенденцию к эволюции в процессе их использования — к тому, что 
часто неправильно называют программным сопровождением. Если быть более 
точным, то сопровождение имеет в виду устранение ошибок; эволюция 
подразумевает внесение изменений в систему в ответ на изменившиеся 
требования к ней; сохранение — использование всех возможных и 
невозможных способов для обеспечения функционирования старой и давно 
утерявшей пригодность системы. К сожалению, опыт показывает, что 
существенный процент затрат на разработку программных систем тратится 
именно на сохранение. 

Сложность управления процессом разработки. Основная задача 
разработчиков состоит в создании иллюзии простоты, защищающей 
пользователей от сложности описываемого предмета или процесса. Размер 
исходных текстов программной системы отнюдь не входит в число ее 
главных достоинств, поэтому исходные тексты стараются сделать более 
компактными, используя при этом уже существующие методы и изобретая 
новые, более мощные. Однако большое число требований к системе иногда 
неизбежно приводит либо к необходимости создания нового программного 
продукта значительных размеров, либо к модификации существующего, что 
также не делает его проще. Всего 20 лет назад программы объемом в 
несколько тысяч строк, написанные на ассемблере, выходили за пределы 
инженерных возможностей. Сегодня обычными стали программные системы, 
размер которых исчисляется десятками тысяч или даже миллионов строк (и 
к тому же на языках высокого уровня). Ни один человек никогда не 
сможет полностью понять такую систему. Даже если мы правильно 
разложили ее на составные части, мы все равно получим сотни, а иногда и 
тысячи отдельных модулей. Поэтому такой объем работ потребует 
привлечения команды разработчиков, хотя в идеале численность этой 

команды должна быть как можно меньшей. Но какой бы она ни была, 

всегда возникнут значительные трудности, связанные с координацией хода 
работ над таким коллективным продуктом. Большее число разработчиков 
подразумевает более сложные связи между ними, особенно если участники 
работ географически удалены друг от друга — ситуация, типичная при 

реализации больших проектов. Таким образом, в случае коллективного 
проекта главной проблемой руководства является поддержание целостности 
основной идеи в ходе работ. 

Гибкость программного обеспечения. Строительные компании обычно 
не имеют деревообрабатывающих заводов для производства строительной 
древесины; было бы также странно, если бы на месте строительства 
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сооружались прокатные станы для ковки стальных балок под будущее 
здание. Однако в программной индустрии такая практика — дело обычное. 
Программирование обладает максимальной гибкостью, и разработчик может 
сам обеспечить себя всеми необходимыми элементами, относящимися к 
любому уровню абстракции. Такая гибкость — чрезвычайно соблазнительное 
качество. Оно, однако, заставляет разработчика создавать самому все 
базовые строительные блоки будущей конструкции, из которых составляются 
элементы более высоких абстрактных уровней. В отличие от строительной 
индустрии, где существуют единые стандарты на многие конструктивные 
элементы и на качества материалов, в программной индустрии таких 
стандартов почти нет. Поэтому программные разработки остаются очень 
кропотливым делом. 

Сложность описания поведения отдельных подсистем. Когда мы кидаем 
вверх мяч, мы можем довольно надежно предсказать его траекторию, 
потому что знаем все силы, действующие на него в нормальных условиях. 
Мы бы очень удивились, если бы, кинув мяч с чуть большей скоростью, 
увидели, что он на середине пути неожиданно остановился и стремительно 
рванулся вертикально вверх 1 *. В недостаточно отлаженной программе 
моделирования палета мяча такая ситуация легко может возникнуть. 

Внутри большой прикладной программы могут существовать сотни и 
даже тысячи переменных и несколько способов контроля за ними. Полный 
список этих переменных, их текущих значений, текущих адресов и стеков 
описывает состояние прикладной программы в каждый момент времени. Так 
как исполнение нашей программы осуществляется на цифровом компьютере, 
мы имеем систему с дискретными состояниями. Аналоговые системы, такие, 
как системы моделирования движения мяча, напротив, являются 
непрерывными. Парнас пишет, что «когда мы говорим, что система 
описывается непрерывной функцией, это означает, что она не содержит 
никаких сюрпризов. Небольшие изменения входных параметров всегда 
вызовут соответственно небольшие изменения выходных» [4]. С другой 
стороны, дискретные системы по определению имеют конечное число 
возможных состояний; в больших системах это число в соответствии с 
правилами комбинаторики достигает громадных значений. Мы стараемся 
спроектировать системы так, чтобы поведение одной части системы 
оказывало минимальное воздействие на поведение другой. Однако переходы 
между дискретными состояниями не могут моделироваться непрерывными 
функциями. Каждое событие, внешнее по отношению к программной 
системе, может перевести ее в новое состояние, и, более того, переход из 
одного состояния в другое не всегда детерминирован. При неблагоприятных 
условиях внешнее событие может нарушить текущее состояние системы из- 
за того, что ее создатели не смогли предусмотреть все возможные варианты 
взаимодействий между событиями. Представим себе пассажирский самолет, в 


11 Наличие хаоса может усложнить поведение даже простых систем. Невозможно точно 
предугадать состояние системы, если оно зависит от случайных факторов. Зная, например, 
начальное положение двух капель воды в потоке, мы не можем точно указать, на каком 
расстоянии друг от друга окажутся эти капли через некоторое время. От случайных 
воздействий зависит поведение практически всех природных систем: атмосферы, химических 
молекул, биологических систем, и даже компьютерных сетей. Хотя, по-видимому, даже в 
хаотичных системах существуют некие скрытые законы, подтверждение тому — тенденция к 
возникновению аттракторов. 
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котором система управления полетом и система электроснабжения 
объединены. Было бы очень неприятно стать свидетелем ситуации, когда 
результатом нажатия кнопки включения головного света одним из 
пассажиров стал бы немедленный ввод самолета в глубокое пикирование. В 
непрерывных системах такое поведение было бы невозможным, но в 
дискретных системах любое внешнее событие может повлиять на любую 
часть внутреннего состояния системы. Это, очевидно, и является главной 
причиной обязательного тестирования наших систем; но дело в том, что, 
исключая, возможно, наиболее тривиальные случаи, всеобъемлющее 
тестирование таких программ провести невозможно. И пока у нас нет ни 
математических инструментов, ни интеллектуальных возможностей для 
полного моделирования поведения больших дискретных систем, при 
определении ее точности мы должны удовлетвориться существующими 
уровнями доверия к системе. 

Трудности на пути создания сложных систем 

«Чем сложнее система, тем ближе она к полному развалу» [5]. 
Строителям редко приходят мысли об установке дополнительного фундамента 
к уже построенному 100-этажному небоскребу; сделать это будет совсем 
недешево, да и, наверняка, ничего не выйдет. Но что удивительно, 
пользователи программных систем совсем нередко ставят подобные задачи 
перед разработчиками. Это, утверждают они, всего лишь технический вопрос 
для программистов. 

Наши неудачные попытки создать сложную программную систему 
реализуются в проектах, которые выходят за пределы установленных сроков 
и бюджетов и к тому же не соответствуют начальным требованиям. Мы 
часто называем это кризисом программного обеспечения, но, честно говоря, 
болезнь, которая продолжается слишком долго, уже не болезнь, она 
становится частью нормального процесса. К сожалению, этот кризис 
приводит к разбазариванию человеческих ресурсов — самого драгоценного 
товара — и к существенному ограничению возможностей создания нового 
продукта. Сейчас просто не хватает достаточного количества хороших 
программистов, чтобы обеспечить всех пользователей нужными им 
программами. Более того, существенный процент персонала, занятого 
разработками в любой организации, часто должен заниматься в основном 
сопровождением и сохранением устаревших программ. Принимая во 
внимание явный и неявный вклад, вносимый индустрией программного 
обеспечения в развитие экономической базы большинства ведущих стран, и 
анализируя пути усиления с помощью программных средств возможностей 
индивидуума, становится ясной невозможность сохранения существующей 
схемы создания программных систем. 

Как мы можем изменить эту ситуацию? Так как проблема возникает в 
целом в результате сложности структуры программных продуктов, мы 
предлагаем сначала изучить способы организации сложных структур в 
других научных дисциплинах. В самом деле, можно привести множество 
примеров успешно функционирующих сложных систем. Некоторые из этих 
систем созданы человеком, такие, как, например, Спейс Шаттл, англо¬ 
французский туннель, или большие фирмы типа IBM. В природе 
существуют еще более сложные системы, например система обмена веществ 
у человека или структура растения. 
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1.2. СТРУКТУРА СЛОЖНЫХ СИСТЕМ 
Примеры сложных систем 

Персональный компьютер (ПК). Персональный компьютер — прибор 
средней степени сложности. Большинство ПК состоит из одних и тех же 
основных элементов: центрального процессора (ЦП), монитора, клавиатуры и 
запоминающего устройства какого-либо типа (либо гибкого диска, либо 
встроенного жесткого диска). Мы можем взять любую из этих частей и 
разложить ее в свою очередь на составляющие. ЦП, например, обычно 
содержит первичную память, арифметико-логическое устройство (АЛУ) и 
шину, к которой подключены периферийные устройства. Каждую из этих 
частей можно также разложить на составляющие: АЛУ состоит из регистров 
и из логики произвольного управления, которые сами состоят из еще более 
простых элементов типа логическое «И», инверторы и т.д. Это пример 
иерархической структуры сложной системы. Персональный компьютер своей 
нормальной работой обязан четкому совместному функционированию каждой 
из его составных частей. В самом деле, мы можем понять, как работает 
компьютер, только когда отдельно рассмотрим каждую его составляющую. 
Таким образом, мы можем изучать устройства монитора и жесткого диска 
независимо друг от друга. Аналогично мы можем изучать АЛУ, не 
рассматривая при этом подсистему первичной памяти. 

Сложные системы не просто иерархичны: уровни их иерархии отражают 
различные уровни абстракции, вытекающие друг из друга, но обладающие 
при этом определенной степенью автономности. И для каждой конкретной 
задачи мы рассматриваем соответствующий уровень. Например, если бы мы 
пытались решить проблему синхронизации с помощью первичной памяти, 
нам предстояло бы аккуратно рассмотреть архитектуру соответствующего 
уровня, но этот уровень абстракции был бы неприемлем, если мы старались 
найти решение в самой прикладной программе. 

Животные и растения. Ботаник старается найти похожие и 
отличительные черты у разных растений, изучая их морфологию, т.е. их 
форму и структуру. Растения — это сложные многоклеточные организмы. В 
результате совместной деятельности различных систем и органов растения 
возникают такие сложные процессы, как фотосинтез и обмен веществ с 
окружающей средой. Растения состоят из трех основных структур (корни, 
ствол, стебли и листья), и каждая из них имеет свое устройство. Корни, 
например, состоят из ветвей, волос, вершины и шапки. Если же сделать 
разрез листа, то мы увидим, что он состоит из эпидермия, мезофилла и 
сосудистой ткани. Каждая из этих структур в свою очередь представляет 
собой набор клеток. Внутри каждой клетки существует следующий уровень 
сложности, который включает хлоропласты, митохондрию, ядро и т.д. По 
аналогии со структурой компьютера части растения формируют иерархию, и 
каждый уровень этой иерархии отражает свой уровень сложности. 

Все составляющие одного уровня абстракции взаимодействуют друг с 
другом вполне определенным способом. Если, например, рассмотреть высший 
уровень абстракции, то корни отвечают за доставку воды и минералов из 
почвы. Корни взаимодействуют со стволами и стеблями, по которым эти 
материалы достигают листьев. Листья в свою очередь используют воду и 
минералы, полученные через стебли, для производства пищи с помощью 
фотосинтеза. 
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На каждом уровне существуют четкие границы между внешней и 
внутренней средой. Мы можем сказать, что части листа работают вместе 
для обеспечения функционирования листа как целого, и почти не 
осуществляют взаимодействия с элементами корней. Проще говоря, 
существует четкое разделение функций между элементами на различных 
уровнях абстракции. 

В компьютере логические схемы «И» используются и в конструкции 
ЦП, и в конструкции жесткого диска. Аналогично большое число 
«унифицированных элементов» имеется во всех частях структурной иерархии 
растения. Это естественный путь для достижения экономии средств 
выражения. Например, клетки служат основными строительными блоками 
всех структур растения; в конечном счете корни, стебли и листья растения 
состоят из клеток. Но при этом существует много различных типов клеток; 
например, клетки, содержащие и не содержащие хлоропласты, клетки со 
стенками, которые пропускают или, наоборот, не пропускают воду, и даже 
живые и неживые клетки. 

При изучении морфологии растения невозможно выделить в нем 
отдельные части, каждая из которых выполняет лишь одну, вполне 
определенную функцию сложного процесса, например фотосинтеза. Также 
фактически не существует отдельных элементов, напрямую координирующих 
деятельность подсистем растения. Отдельные его части действуют достаточно 
сложным образом в качестве независимых агентов, совместное 
функционирование которых полностью определяет поведение системы. Таким 
образом, поведение растения обеспечивается суммой бессмысленных на 
первый взгляд действий этих агентов. 

Структура строения многоклеточных животных также является 
иерархической: клетки формируют ткани, ткани работают вместе как 
органы, группы органов определяют системы (пищеварительную, например) 
и так далее. Природа умеет создавать системы, отличающиеся высокой 
степенью универсальности базовых элементов: основной строительный блок 
всех растений и животных — клетка. Естественно, между этими двумя 
типами клеток существуют различия. Клетки растения, например, 
заключены в твердую целлюлозную оболочку в отличие от клеток 
животных. Но, несмотря на данные различия, обе указанные структуры, 
несомненно, являются клетками. Это удивительный пример схожести 
строения систем, относящихся к разным сферам биологической деятельности. 

То же самое можно сказать и о некоторых механизмах надклеточного 
уровня. И растения, и животные используют сосудистую систему для 
транспортировки питательных веществ. И у тех и у других может 
существовать различие полов внутри одного вида. 

Материя. Исследования в таких разных областях, как астрономия и 
ядерная физика, дают нам много примеров очень сложных систем. 
Рассмотрев эти две дисциплины, мы найдем дополнительные примеры 
структурной иерархии. Астрономы занимаются изучением галактик и их 
составляющих: звезд, планет и других небесных тел. Ядерные физики имеют 
дело со структурной иерархией физических тел совсем другого масштаба. 
Атомы состоят из электронов, протонов и нейтронов; электроны, по- 
видимому, являются элементарными частицами, но протоны, нейтроны и 
другие частицы формируются из еще более мелких компонент, называемых 
кварками. 

2 Гради Буч 
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Однако эти две совершенно различные по масштабу и структуре 
физические системы подчиняются одним и тем же законам взаимодействия. 
На самом деле оказывается, что во Вселенной существуют всего четыре 
типа сил: гравитационная, электромагнитная, сильное взаимодействие и 
слабое взаимодействие. И многие законы физики, подразумевающие наличие 
этих элементарных сил, такие, как закон сохранения энергии и момента, 
можно применить и к галактикам, и к кваркам. 

Общественные институты. Как последний пример сложных систем, 
давайте рассмотрим структуру общественных институтов. Группы людей 
собираются вместе для решения задач, которые не могут быть решены 
отдельными личностями. Некоторые организации быстро распадаются, а 
некоторым удается продержаться на протяжении нескольких человеческих 
жизней. Чем больше организация, тем отчетливее видна в ней 
иерархическая структура. Мультинациональные корпорации состоят из 
компаний, которые в свою очередь состоят из подразделений, содержащих 
различные филиалы. Последним принадлежат уже отдельные офисы и т.д. 
На протяжении существования организации границы между этими частями 
могут изменяться, так что с течением времени старая иерархия путем 
эволюции трансформируется в новую, более стабильную. 

Отношения между разными частями большой организации такие же, 
как и между компонентами компьютера, растения, галактики. Таким 
образом, степень взаимодействия между сотрудниками одного учреждения, 
несомненно, выше, чем между сотрудниками двух разных учреждений. На 
первый взгляд это не совсем так: почтовый клерк, например, обычно не 
взаимодействует с исполнительным директором. компании, в основном 
обслуживая посетителей. Однако клерка и директора, принадлежащих 
разным уровням иерархии, объединяет общий механизм функционирования 
компании. Работа и клерка, и директора оплачивается одной финансовой 
организацией, и оба они пользуются общей аппаратурой, в частности 
внутренней телефонной системой компании для решения своих задач. 

Пять признаков сложной системы 

Основываясь на работе Саймона и Эндо, Куртуа предлагает следующие 
пять признаков сложной системы. 

1. «Сложность часто представляется в виде иерархии. Сложная система 
обычно состоит из взаимозависимых подсистем, которые в свою очередь 
также могут быть разделены на подсистемы, и т.д., вплоть до самых 
низших уровней абстракции» [6]. 

Тот факт, что многие сложные системы имеют разложимую на 
составляющие иерархическую структуру, является главным фактором, 
позволяющим нам понять, описать и даже «увидеть» такие системы и их 
подсистемы [7]. В самом деле, скорее всего мы сможем понять лишь те 
системы, которые имеют иерархическую структуру. 

2. Выбор низшего уровня абстракции достаточно произволен и в 
большой степени определяется наблюдателем. 

Низший уровень для одного наблюдателя может оказаться уровнем 
достаточно высокой абстракции для другого. 

Саймон называет иерархические системы «разложимыми», если они 
могут быть разделены на четко узнаваемые части, и «почти разложимыми», 
если их составляющие не являются абсолютно независимыми. 
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3. «Внутриэлементные связи обычно сильнее межэлементных связей. 
Поэтому высокочастотные взаимодействия внутри структуры оказываются 
естественным образом отделены от низкочастотных взаимодействий между 
структурами» [8]. 

Различие между внутри- и межэлементыми взаимодействиями 
обусловливает разделение системы на абстрактные автономные части, 
которые можно изучать по отдельности. 

Как мы уже говорили, многие сложные системы организованы 
достаточно экономно в смысле способов выражения. Отсюда — следующий 
признак сложных систем. 

4. «Иерархические системы обычно состоят из нескольких подсистем 
разного типа, реализованных в различном порядке и в разнообразных 
комбинациях» [9 ]. 

Иногда (например, клетки растений и животных) можно обнаружить 
подсистемы, общие для различных сфер функционирования всей системы. 

Выше мы говорили, что сложные системы имеют тенденцию к развитию 
во времени. Саймон считает, что сложные системы будут развиваться из 
простых гораздо быстрее, если для них существуют устойчивые 
промежуточные формы [10]. 

5. «Работающая сложная система неизбежно оказывается результатом 
развития работающей простой системы... Сложная система, разработанная от 
начала до конца на бумаге, никогда не работает и нельзя заставить ее 
заработать. Вы должны начать с работающей простой системы» [11]. 

В процессе развития системы объекты, которые сначала считаются 
сложными, начинают рассматриваться как элементы низших уровней 
абстракции, из которых затем строятся более сложные системы. 

Организованная и неорганизованная сложность 

Каноническая форма сложной системы. Обнаружение общих 
абстракций и их механизмов значительно облегчает понимание сложных 
систем. Опытный пилот, например, соориентировавшись всего за несколько 
минут, может взять на себя управление тяжелым реактивным самолетом, на 
котором он раньше никогда не летал, и спокойно его вести. Определив 
элементы, общие для всех подобных самолетов (такие, как руль 
направления, элероны и механизм управления тягой), пилот прежде всего 
должен найти отличия этого самолета от других. Если пилот уже знает, 
как управлять данным самолетом, ему гораздо легче научиться управлять 
самолетом, похожим на него. 

В этом примере мы использовали термин «иерархия» в довольно 
широком смысле. Наиболее интересные системы содержат много разных 
иерархий. В самолете, например, можно выделить системы силовой 
установки, управления полетом и т.д. Такое разбиение дает структурную 
иерархию типа «это — часть того». Но одновременно эту же систему можно 
рассмотреть по-другому. Например, турбореактивный двигатель — особый 
тип реактивного двигателя, а «Pratt and Whithey TF30* — особый тип 
турбореактивного двигателя. Определенный другим путем «реактивный 
двигатель* представляет обобщение свойств, присущих любому типу 
реактивного двигателя; турбореактивный двигатель — это просто особый тип 
реактивного двигателя со свойствами, которые отличают его, например, от 
прямоточного двигателя. Эта вторая иерархия представляет собой «типовую» 
иерархию. Исходя из нашего опыта, мы сочли необходимым рассмотреть 
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систему с двух точек зрения, выделив типовую и структурную иерархии. В 
гл. 2 мы назовем эти иерархии соответственно структурой классов и 
структурой объектов. 

Если мы объединим понятия структуры классов и структуры объектов с 
пятью признаками сложных систем, мы найдем, что фактически все 
сложные системы можно представить одной и той же (канонической) 
формой, представленной на рис. 1-1. Здесь мы видим две разные иерархии, 
принадлежащие одной системе: структуру классов и структуру объектов. 
Каждая иерархия является многоуровневой, в которой более абстрактные 
классы и объекты построены на базе более примитивных. Выбор класса или 
объекта, соответствующего низшему уровню абстракции, зависит от 
конкретной задачи. Среди объектов одного уровня существуют четко 
выраженные связи, особенно это касается компонентов структуры объектов. 
Любому рассматриваемому уровню абстракции соответствует свой уровень 
сложности. Заметьте также, что структуры классов и объектов не являются 
независимыми: каждый объект в структуре объектов представляет 

определенный класс. Как видно из рис. 1-1, объектов в сложной системе 
обычно гораздо больше чем классов. Если бы мы не показали «классовую 
структуру» нашей системы, нам пришлось бы дублировать знания о 
свойствах каждой ее отдельной части. С введением данной структуры мы 
размещаем эти основные свойства в одном месте. 

Обычно наиболее успешными программными системами являются те, в 
которых заложены хорошо продуманные структуры классов и объектов и 
которые обладают пятью признаками сложных систем, описанными выше. 
Оценим важность этого наблюдения и выразимся более категорично: очень 
редко можно встретить программную систему, разработанную точно по 
графику, уложившуюся в бюджет и удовлетворяющую требованиям 
заказчика, в которой бы не были учтены эти особенности. 

Человеческие возможности и сложные системы. Если мы знаем, какой 
должна быть конструкция сложных программных систем, то почему при 
разработке таких систем мы сталкиваемся с серьезными проблемами? Как 
показано в гл. 2, понятие организованной сложности программ (основные 
принципы создания которой мы будем обозначать понятием «объектный 
подход») относительно ново. Существует, однако, еще одна, по-видимому, 
главная причина: ограниченность биологических возможностей человека. 

Когда мы начинаем анализировать сложную систему, в ней 
обнаруживается много составных частей, которые взаимодействуют друг с 
другом различными сложными способами, причем ни сами части системы, 
ни пути их взаимодействия не обнаруживают никакого сходства. Это пример 
неорганизованной сложности. Когда мы начинаем в процессе проектирования 
вносить в систему элементы организованности, мы должны думать сразу о 
многих вещах. Например, в системе управления воздушным движением 
необходимо одновременно контролировать состояние многих летательных 
аппаратов, в том числе такие их параметры, как положение, скорость и 
направление полета. При анализе дискретных систем необходимо 
рассматривать большие, сложные и не всегда детерминированные 
пространства состояний. К сожалению, один человек не может отслеживать 
все это одновременно. Психологи (например, Миллер) считают, что 
максимальное количество единиц информации, которое человеческий мозг 
может одновременно обработать, не превышает 7 [12]. Этот объем связан, 





по-видимому, с объемом краткосрочной памяти у человека. Саймон отмечает 
также, что дополнительным ограничивающим фактором является скорость 
обработки мозгом поступающей информации: ему требуется примерно 5 с на 
каждое новое событие [13]. Таким образом, мы столкнулись с серьезным 
препятствием: требуемая сложность программных систем возрастает, а 
способности нашего мозга контролировать эту сложность остаются на 
прежнем уровне. Как нам выйти из данного затруднительного положения? 


Объекты 



Рис. 1-1. Каноническая форма сложной декомпозиции. 
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1.3. ВНЕСЕНИЕ ПОРЯДКА В ХАОС 
Декомпозиция 

«Способ управления сложными системами был известен еще в 
древности: divide et impera (разделяй и властвуй)* [14]. При 
проектировании сложной программной системы необходимо составлять ее из 
небольших подсистем, каждую из которых можно отладить независимо от 
других. В этом случае мы не выходим за пределы возможностей человека, 
отпущенных ему природой: при разработке любого уровня системы нам 
необходимо будет одновременно держать в уме информацию лишь о 
немногих ее частях (отнюдь не о всех). В самом деле, правильная 
декомпозиция непосредственно определяет сложность, присущую программной 
системе, обеспечивая разделение пространства состояний системы [15]. 

Алгоритмическая декомпозиция. У большинства из нас понятие 
«проектирование» ассоциируется со структурным проектированием по методу 
«сверху вниз», и мы воспринимаем декомпозицию как обычное разделение 
алгоритмов, где каждый модуль системы выполняет один из важных этапов 
общего процесса. На рис. 1-2 приведен пример результата структурного 
проектирования: структурная схема, которая иллюстрирует связи между 
различными функциональными элементами системы. 

Данная структурная схема отражает конструкцию программной 
подсистемы, осуществляющей изменение содержания управляющего файла. 
Она была автоматически получена путем анализа диаграммы потоков 
данных экспертной системой, которой известны правила структурного 
проектирования [16]. 

Объектно-ориентированная декомпозиция. Мы полагаем, что существует 
альтернативный способ декомпозиции этой подсистемы. На рис. 1-3 мы 
разделили подсистему, выбрав в качестве критерия декомпозиции 
принадлежность ее элементов к различным абстракциям данной предметной 
области. Вместо того чтобы разделять задачу на шаги типа «Получить 



Рис. 1-2. Алгоритмическая декомпозиция. 
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изменения в отформатированном виде» и «Прибавить к контрольной сумме», 
мы идентифицировали объекты типа «Основной файл» и «Контрольная 
сумма», которые соответствуют словарю предметной области. 

Хотя обе конструкции служат решению одной проблемы, они делают 
это разными способами. Во второй схеме мир представлен списком 
автономных действующих лиц, которые взаимодействуют друг с другом, 
чтобы обеспечить поведение системы, соответствующее более высокому 
уровню. «Получить изменения в отформатированном виде» больше не 
присутствует в качестве независимого алгоритма; вместо этого он существует 
в виде операций над объектом «Файл изменений*. При вызове этой 
операции создается другой объект — «Изменение в строке». Каждый объект 
нашей системы обладает своим собственным поведением, моделирующим 
поведение реального объекта. С этой точки зрения объект является вполне 
определенной вещью, которая демонстрирует вполне определенное поведение. 
Объекты производят действия, и мы просим их сделать то-то и то-то, 
посылая им сообщения. Так как наша декомпозиция основана на объектах, 
а не на алгоритмах, мы называем ее объектной декомпозицией. 

Алгоритмическая и объектно-ориентированная декомпозиции. Как 
правильней разделять сложную систему — по алгоритмам или по объектам? 
И по алгоритмам, и по объектам. Разделение по алгоритмам концентрирует 
внимание на порядке происходящих событий, а разделение по объектам 
придает особое значение факторам, либо вызывающим действия, либо 
являющимся объектами приложения этих действий 1 ). 

Однако мы не можем сконструировать сложную систему одновременно 
двумя способами, тем более что эти способы различны по сути. Мы можем 
начать разделение системы либо по алгоритмам, либо по объектам, а затем, 
используя полученную структуру, попытаться рассмотреть проблему с другой 
точки зрения. 

Опыт показывает, что полезнее сначала применить объектный подход. 
Это поможет нам лучше понять структуру будущей программной системы. 
Выше мы уже применяли объектный подход при описании систем типа 
компьютеры, растения, галактики и общественные институты. В гл. 2 и 7 
будут рассмотрены преимущества объектной декомпозиции. Ее использование 
дает возможность создавать программные системы меньшего размера путем 
использования общих механизмов, обеспечивающих необходимую экономию 
выразительных средств. 

Объектно-ориентированные системы более открыты и легче поддаются 
модернизации, потому что конструкция таких систем базируется на 
устойчивых промежуточных формах. Кроме того, объектная декомпозиция 
уменьшает риск создания сверхсложных программных систем, так как она 
предполагает эволюционный путь развития системы на базе относительно 
небольших подсистем. Более того, объектная декомпозиция непосредственно 
определяет сложность программ, помогая нам принимать верные решения, 
когда вопрос касается разделения понятий в больших пространствах 
состояний. 


11 Лэнгдон замечает, что этот вопрос поднимался еще в древние времена. Как он утверждает: 
«Вэддингтон писал, что двойственность взглядов можно проследить вплодь до древних греков. 
Пассивный взгляд выдвигался Демокритом, который утверждал, что мир состоит из атомов. Он 
концентрирует внимание на вещах. С другой стороны, классический представитель активного 
взгляда на мир Гераклит уделял главное внимание процессу» [17]. 
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Рис. 1-3. Объектно-ориентированная декомпозиция. 

Преимущества объектно-ориентированных систем становятся видны при 
рассмотрении в гл. 8 — 12 ряда примеров прикладных программ, 

предназначенных для решения различных задач. 

Абстракции 

Выше мы говорили об экспериментах Миллера, в которых было 
установлено, что обычно человек может одновременно воспринять не более 
семи событий. Это число, по-видимому, не зависит от количества 
информации, содержащейся в событиях. Как замечает Миллер: «Размер 
нашей памяти накладывает жесткие ограничения на количество информации, 
которое мы можем воспринять, обработать и запомнить. Организуя поток 
входной информации одновременно по нескольким разным каналам и в виде 
последовательности отдельных событий, мы можем прорвать 
информационный затор» [18]. Он называл это декодированием, сейчас это 
называют разбиением или выделением абстракций. 

Вулф описывает процесс декодирования информации в мозгу у человека 
следующим образом: «Люди обладают чрезвычайно эффективными 

механизмами обработки сложных сообщений, поступающих к ним через 
органы чувств. Они абстрагируются от них. Не в состоянии полностью 
воссоздать сложный объект, они просто игнорируют не слишком важные 
детали и, таким образом, имеют дело с обобщенной, идеализированной 
моделью объекта» [19]. Например, изучая процесс фотосинтеза, мы 
концентрируем внимание на химических реакциях в определенных клетках 
листа и не обращаем внимание на остальные части — корни, стебли и т.д. 
И хотя мы при этом также ограничены количеством информации, которую 
можем воспринять в каждый отдельный момент, появляется возможность, 
используя абстрактные понятия, обрабатывать потоки сообщений, 
обладающие гораздо большей плотностью. 

В гл. 2 понятие абстракции рассмотрено более детально. 
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Методы проектирования программных систем 

Мы решили, что будет полезно, если мы разграничим понятия 

«метод» и «методология». Метод — это последовательный процесс 

создания ряда модйлей, которые описывают вполне определенными 
средствами различные стороны разрабатываемой программной системы. 
Методология — это совокупность механизмов, применяемых в процессе 
разработки программного обеспечения и объединенных одним общим 
филосовским подходом. Эти механизмы необходимы по нескольким 
причинам. Во-первых, они упорядочивают процесс создания программных 
систем, являясь общими для всей группы разработчиков. Кроме того, 
позволяют менеджерам в процессе разработки оценить степень прогресса. 
Методы появились как ответ на растущую сложность программных 

систем. Раньше, например, очень трудно было написать большую 

программу, потому что возможности ЭВМ были ограничены. При 
разработке и развитии программных комплексов ограничения на них 
устанавливались, исходя из объема оперативной памяти, скорости 
считывания информации с вторичных носителей (ими служили магнитные 
барабаны) и быстродействия процессора, значение тактовой частоты 
которого измерялось сотнями микросекунд. В 60 — 70-е годы 

эффективность применения компьютеров резко возросла, так как цены на 
них стали падать, а возможности ЭВМ увеличились. В результате стало 
выгодно, да и необходимо создавать все больше прикладных программ 
повышенной сложности. В качестве основных инструментов создания 
программных продуктов начали применяться алгоритмические языки 
высокого уровня. Эти языки расширили возможности отдельных 
программистов и групп разработчиков, что в свою очередь привело к 
увеличению уровня сложности программных систем. 

В 60—70-е годы было разработано много методов, помогающих 
справиться с растущей сложностью программ. Наибольшее 
распространение получило структурное проектирование по методу сверху 
вниз, или комбинированный метод. Он был непосредственно основан на 
топологии традиционных языков высокого уровня типа FORTRAN и 
COBOL. В этих языках основной базовой единицей является 
подпрограмма, и программа в целом принимает форму дерева, в котором 
одни подпрограммы в процессе работы вызывают другие подпрограммы. 
Структурное проектирование использует именно такой подход: 
алгоритмическая декомпозиция применяется для разбиения большой 
задачи на маленькие. 

Начиная с 60—70-х годов стали появляться компьютеры еще 
больших, поистине громадных возможностей. Значение структурного 
подхода осталось прежним, но как замечает Стайн, «оказалось, что 
структурный подход не работает, если объем программы превышает 
приблизительно 100 000 строк» [20]. В последнее время появились 
десятки методов, в большинстве которых устранены очевидные недостатки 
структурного проектирования. Наиболее удачные методы были 
разработаны Питерсом [21], Яу и Цаем [22], а также фирмой «Teledyne 
— Brown Engineering» [23]. Большинство этих методов представляют 
собой вариации на одну и ту же тему. Соммервиль, однако, предлагает 
разделить их на три основные группы [24]: 
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* Метод структурного проектирования сверху вниз. 

* Метод организации потоков данных. 

* Объектно-ориентированное проектирование. 

Примеры методов структурного проектирования приведены в работах 
Йордана и Константина [25], Маерса [26] и Пейджа-Джонсона [27]. 
Основы его изложены в работах Вирта [28, 29] и Даля, Динкстры и 
Хоара [30]; интересный вариант структурного подхода можно найти в 
работе Миллса, Лингера и Хевнера [31 ]. В каждом из этих подходов 
присутствует алгоритмическая декомпозиция. Следует отметить, что 
большинство существующих программ написано, по-видимому, в 
соответствии с одним из этих методов. Тем не менее структурный подход 
не позволяет выделять абстракции и обеспечивать защиту доступа к 
данным, не предоставляет он также достаточных средств для организации 
параллелизма. Структурный метод не может обеспечить создание 
предельно сложных систем, и он, как правило, неэффективен при 
использовании объектно-ориентированных языков программирования. 

Метод организации потоков данных полнее всего описан в ранней 
работе Джексона [32, 33], а также Уорниера и Орра [34]. В этом мето¬ 
де структура программной системы строится как организация преобразова¬ 
ний входных потоков в выходные. Метод организации потоков данных, 
как и структурный метод, с успехом применялся при решении ряда 
сложных задач, в частности, в системах информационного обеспечения, 
где существуют прямые связи между входными и выходными потоками 
системы и где не требуется уделять много внимания быстродействию. 

Объектно-ориентированное проектирование (OOD) — это подход, 
основы которого изложены в данной книге. В основе OOD лежит 
представление о том, что программную систему необходимо проектировать 
как совокупность взаимодействующих друг с другом объектов, 
рассматривая каждый объект как экземпляр определенного класса, причем 
классы при этом образуют иерархию. Объектно-ориентированный подход 
отражает топологию новейших языков высокого уровня, таких, как 
Smalltalk, Object Pascal, C++, CLOS и Ada. 


Иерархия 

Другим способом, расширяющим возможности обработки потоков данных 
программной системой, является организация внутри системы иерархии 
классов и объектов. Структура объектов дает схему их взаимодействий друг 
с другом, которые осуществляются с помощью механизмов взаимодействий. 
Структура класса не менее важна — она определяет избыточность средств 
внутри системы. Зачем, например, изучать фотосинтез каждой клетки 
отдельного листа растения, когда достаточно изучить одну такую клетку, 
потому что скорее всего все остальные ведут себя подобным же образом. И 
хотя мы рассматриваем каждый объект определенного типа как отдельный, 
можно предположить, что его поведение будет похоже на поведение других 
объектов того же типа. Классифицируя объекты по группам родственных 
абстракций (например, типы клеток растений и клеток животных), мы 
четко разделяем общие и отличительные свойства разных объектов, что 
помогает нам затем создать их собственную сложную структуру [35]. 

Определить иерархии в сложной программной системе не всегда легко, 
так как это требует разработки моделей многих объектов, поведение 
каждого из которых может отличаться чрезвычайной сложностью. Однако 
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после их определения структура сложной системы и в свою очередь наше ее 
понимание сразу во многом проясняются. В гл. 3 в деталях рассматривается 
природа классов и иерархий объектов, а в гл. 4 описываются способы, 
облегчающие понимание их структуры. 

1.4. ПРОЕКТИРОВАНИЕ СЛОЖНЫХ СИСТЕМ 
Методология проектирования как наука и искусство 

На практике каждая инженерная дисциплина — касается ли она 
строительства, механики, химии, электроники или программирования — 
включает элементы и науки, и искусства. Петроски по этому поводу 
утверждает следующее: «Понятие «разработка новых структур* предполагает 
и полет фантазии, и синтез опыта и знаний — все то, что необходимо 
художнику для реализации своего замысла на холсте или бумаге. И после 
того, как этот замысел созрел в голове инженера-художника, он обязательно 
должен быть проанализирован инженером-ученым со всей тщательностью, 
присущей настоящему ученому» [36]. 

Когда встает задача разработки совершенно новой системы, роль 
инженера-художника выдвигается на первый план. А ведь это довольно 
распространенный случай, особенно если мы имеем дело с системами, 
обладающими обратной связью, с системами управления и контроля, когда 
нам приходится писать программное обеспечение, требования к которому 
нестандартны, и для процессора, специально сконструированного для 
решения предложенной задачи. В других случаях, например при создании 
прикладных научных средств, инструментов для исследований в области 
искусственного интеллекта или для систем обработки информации, 
требования к системе могут быть хорошо и точно определены, но 
определены таким образом, что соответствующий им технический уровень 
разработки выходит за пределы существующих технологий. Нам, например, 
могут предложить создать систему, обладающую большим быстродействием, 
большей вместимостью или имеющей гораздо более мощные функциональные 
возможности по сравнению с уже существующими программными 
комплексами. Во всех этих случаях мы будем стараться использовать 
знакомые абстракции и механизмы («устойчивые промежуточные формы» в 
соответствии с терминологией, предложенной Саймоном) как основу будущей 
системы. При наличии большой библиотеки стандартных программных 
модулей инженер-программист должен просто по-новому скомпоновать эти 
модули таким способом, чтобы удовлетворить всем явным и неявным 
требованиям к системе, точно так же как художник или музыкант 
раздвигает пределы своих возможностей при создании новых произведений. 
Но так как подобных богатых библиотек практически не существует, 
инженер-программист может, к сожалению, обычно использовать лишь 
относительно небогатый список готовых модулей. 

Цели проектирования 

В любой инженерной дисциплине под проектированием обычно понима¬ 
ется некий строгий подход, с помощью которого мы ищем пути решения 
определенной проблемы, обеспечивая, таким образом, переход от требований 
к их исполнению. В контексте дисциплины инженерного программирования 
Мостоу определил цель проектирования создание — системы, которая: 
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* «Удовлетворяет данным (возможно, неформальным) функциональным 
требованиям. 

* Имеет приемлемую цену. 

* Удовлетворяет явным и неявным требованиям по эксплуатационным 
качествам и ресурсопотреблению. 

* Удовлетворяет явным и неявным критериям дизайна. 

* Удовлетворяет требованиям к самому процессу разработки, таким, 
например, как его стоимость и продолжительность, а также не требует 
привлечения дополнительных инструментальных средств» [37]. 

Проектирование подразумевает учет противоречивых требований. 
Продуктами его являются модели, позволяющие нам понять структуру 
будущей системы, сбалансировать требования и наметить схему ее 
применения. 

Важность построения модели. Моделирование широко распространено во 
всех инженерных дисциплинах. Причиной этому является то, что оно 
реализует принципы декомпозиции, абстракции и иерархии [38 ]. Каждая 
модель описывает определенную часть рассматриваемой системы, а мы в 
свою очередь строим новые модели на базе старых, в которых более менее 
уже успели разобраться. Модели дают нам возможность исследовать 
недостатки системы в условиях, задаваемых нами самими. Мы оцениваем 
поведение каждой модели в обычных и необычных ситуациях, а затем 
проводим соответствующие доработки, если их поведение нас чем-то не 
удовлетворяет. 

Как мы уже сказали выше, чтобы понять во всех тонкостях поведение 
сложной системы, приходится использовать не одну модель. Например, 
проектируя компьютер, инженер-электронщик должен рассматривать 
электронную схему и знать при этом физическое расположение элементов 
на плате. Электронная схема формирует логическую картину компоновки 
системы, помогая инженеру разобраться в том, каким образом происходит 
взаимодействие между ее различными элементами. Схема платы 
представляет собой план физической реализации системы, ограниченный 
размером платы, потребляемой мощностью и типами имеющихся 
микроэлементов. С этой точки зрения инженер может независимо друг от 
друга оценивать такие параметры системы как температурное распределение 
и технологичность. Проектировщик платы может также рассматривать 
динамические и статические особенности разрабатываемой системы. 
Аналогично инженер-электрик может использовать диаграммы, 
иллюстрирующие статические связи между различными элементами, и 
временные диаграммы, отражающие поведение элементов во времени. Затем 
инженер может применить осциллограф или цифровой анализатор для 
проверки точности статических и динамических схем. 

Элементы методов проектирования программного обеспечения. Ясно, 
что не существует такого универсального метода, который проведет 
инженера-программиста по пути от требований к сложной программной 
системе до их выполнения. Проектирование сложной программной системы 
отнюдь не сводится к следованию некоему набору рецептов. Скорее это 
постепенный и итеративный процесс. И тем не менее использование методов 
проектирования вносит в процесс разработки определенную организованность. 
Инженеры-программисты разработали десятки различных методов, которые 
мы можем классифицировать по трем категориям. Несмотря на различия, 
эти методы имеют что-то общее. Их, в частности, обьединяет следующее: 
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Рис. 1-4. Модели объектно-ориентированного проектирования. 


* Условные обозначения Язык для описания каждой модели. 

* Процесс Правила упорядоченного проектирования модели. 

* Инструменты Средства, которые ускоряют процесс создания 

моделей, определяют законы их 
функционирования и помогают выявлять ошибки 
в процессе разработки. 


Хороший метод проектирования базируется на солидной теоретической 
основе и при этом дает программисту известную степень свободы в выборе 
выразительных средств. 

Модели объектно-ориентированного проектирования. Существует ли 
наилучший метод проектирования? Если и существует, то пока он никому 
не известен. Этот вопрос можно поставить следующим образом: как 
наилучшим способом разделить сложную систему на подсистемы? Еще раз 
напомним, что полезнее всего создавать такую модель системы, которая 
основывается на объектах, принадлежащих проблемной области, и 
сформирована как результат применения объектно-ориентированной 
декомпозиции. 

Объектно-ориентированное проектирование — это метод, логически при¬ 
водящий нас к декомпозиции. Применяя объектно-ориентированное проекти¬ 
рование, мы создаем открытые для изменений программы, собранные из ог¬ 
раниченного числа универсальных блоков. Правильно разделив систему на 
относительно автономные небольшие подсистемы и по отдельности отладив 
каждую из них, мы в гораздо большей степени можем быть затем уверены, 
что наш конечный продукт будет свободен от ошибок. Таким образом, мы 
уменьшаем риск при разработке сложных программных систем. 

Важность построения моделей при проектировании сложных систем дик¬ 
тует необходимость наличия нескольких типов моделей. Они представлены 
на рис. 1-4 и охватывают весь спектр важнейших конструкторских решений, 
которые необходимо рассматривать при разработке сложной системы. В гл. 5 
подробно рассмотрен каждый из четырех типов моделей. В гл. 6 описан 
процесс объектно-ориентированного проектирования, представляющий собой 
последовательную цепь шагов по созданию и обеспечению развития данных 
моделей. В гл. 7 рассмотрены конкретные меры по управлению ходом работ 
с использованием объектно-ориентированного проектирования. 
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В этой главе мы привели доводы в пользу применения объектно- 
ориентированного проектирования для создания сложных структур при 
разработке программных систем. Кроме того, мы определили ряд 
преимуществ, достигаемых в результате применения такого подхода. Прежде 
чем мы начнем изучать сам процесс объектно-ориентированного 
проектирования, мы изучим те принципы, на которых он основан: 
выделение абстракций, ограничение доступа, модульность, иерархия, 
типирование, параллельность и устойчивость. 

Выводы 

* Программам присуща сложность, которая нередко превосходит возможности 
человеческого разума. 

* Сложные структуры часто принимают форму иерархии; полезно 
моделировать и «типовую*, и «структурную* иерархии сложной системы. 

* Сложные системы обычно создаются на основе устойчивых промежуточных 
форм. 

* Познавательные способности человека ограничены; мы можем раздвинуть 
их рамки, используя методы декомпозиции, выделения абстракций и 
создания иерархий. 

* Сложные системы можно исследовать, концентрируя основное внимание 
либо на объектах, либо на процессах; выгоднее рассматривать систему как 
упорядоченную совокупность объектов, которые в процессе взаимодействия 
друг с другом обеспечивают функционирование системы как единого 
целого. 

* Объектно-ориентированное проектирование — метод, использующий 
объектную декомпозицию; объектно-ориентированный подход имеет свою 
систему условных обозначений и предлагает богатый набор логических и 
физических моделей для проектирования систем высокой степени 
сложности. 

Дополнительная литература 

Вопросы, связанные с разработкой сложных программных систем, хоро¬ 
шо проработаны в классических работах Brooks [Н, 1975, 1987]. Glass [Н, 
1982], the Defense Science Board {H, 1987] и the Joint Service Task Force 
[H, 1982] могут дать дополнительную информацию по применению совре¬ 
менного программного обеспечения. Работа Simon [А, 1982] — полезный 
справочник по структурам сложных систем; Courtois [А, 1985] применяет 
эти идеи в области программного обеспечения. Peter [I, 1986] и Petroski [I, 
1985] исследуют сложные структуры применительно к общественным и фи¬ 
зическим системам. В работе Flood ana Carson [А, 1956] представлены тео¬ 
ретические исследования сложных структур с помощью теории систем. До¬ 
клад Miller [А, 1956] содержит эмпирические доказательства наличия огра¬ 
ничений на человеческие познавательные способности. Существует целый 
ряд прекрасных справочников по программированию. Ross, Goodenoudh and 
Irvine [H, 1980] и Zelkowitz [Н, 1978] — два классических документа, со¬ 
держащие все необходимые сведения о науке программирования. По этому 
же предмету существуют большие работы Jensen and Tonies [Н, 1979 Т, 
Sommerville [Н, 1985], Vick and Ramamoorthy [H, 1984], Wegner [H, 1980] 
и Pressman [Н, 1987]. Другие статьи, относящиеся к созданию программно¬ 
го обеспечения, можно наити в работах Yourdon [Н, 1979] и Freeman and 
Wasserman [Н, 1983]. Gleick [I, 1987] предлагает читателю доступно напи¬ 
санное введение в науку хаоса. 



Глава 2 


Объектный подход 

В основе объектно-ориентированного проектирования (OOD) лежит объ¬ 
ектный подход. Основными принципами являются: абстрагирование, ограни¬ 
чение доступа, модульность, иерархичность, типизация, параллелизм и ус¬ 
тойчивость. Эти принципы не новы, однако, именно в объектном подходе 
они объединены для решения общей задачи. 

Объектно-ориентированное проектирование принципиально отличается от 
традиционных подходов структурного проектирования, так как подразумевает 
иной подход к процессу декомпозиции, а получаемый программный продукт 
по архитектуре в значительной степени выходит за рамки традиционных 
представлений. Отличия обусловлены тем, что структурное проектирование 
основано на структурном программировании, тогда как в основе объектно- 
ориентированного проектирования лежит методология объектно-ориентирован¬ 
ного программирования (OOP). К сожалению, единого понимания термина 
«объектно-ориентированное программирование» пока не достигнуто. Рентч 
высказал следующее предположение: «В 1980-х годах объектно-ориентирован¬ 
ное программирование будет занимать такое же место, которое занимало 
структурное программирование в 1970-х годах. Бесспорно, продукция всех 
фирм будет ориентирована на поддержку OOP. Каждый программист в той 
или иной степени ёудет использовать OOP. Но не все будут понимать 
причины этого положения» [1 ]. 

В этой главе сделана попытка выявить особенности OOD и отличия 
этого метода проектирования от других с учетом роли семи перечисленных 
выше элементов объектного подхода. 

2.1. СТАНОВЛЕНИЕ ОБЪЕКТНОГО ПОДХОДА 
Тенденции в методологии проектирования программных 
средств 

Поколения языков программирования. Если проследить короткую, но 
пеструю историю развития методов программирования, можно выделить две 
основные тенденции: 

* Перемещение акцентов от программирования отдельных деталей к про¬ 
граммированию более крупных компонент. 

* Развитие и совершенствование языков программирования высокого уровня. 

Большинство современных коммерческих программных систем существен¬ 
но сложнее и объемнее, чем их предшественники. Рост сложности обусловил 
проведение серьезных исследований в области методологии проектирования 
программных систем; в частности, были разработаны методы декомпозиции, 
абстрагирования и построения иерархии. Кроме того, были созданы более 
выразительные языки программирования. Возникла тенденция перехода от 
процедурных языков программирования (описывающих действия компьютера) 
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к декларативным языкам (описывающим ключевые абстракции проблемной 
области). 

Вэгнер [2] следующим образом сгруппировал наиболее известные языки 
программирования высокого уровня в их поколении: 


* Первое поколение (1954—1958) 
FORTRAN I 

ALGOL-58 
Flowmatic 
IPL V 

* Второе поколение (1959—1961) 
FORTRAN II 

ALGOL- 60 
COBOL 

Lisp 

* Третье поколение (1962—1970) 
PL/1 

ALGOL-68 

Pascal 

Simula 


Математические формулы 
Математические формулы 
Математические формулы 
Математические формулы 

Подпрограммы, раздельная компи¬ 
ляция 

Блочная структура, типы данных 
Описание данных, работа с фай¬ 
лами 

Обработка списков, указатели 

Vortran+ALGOL+COBOL 
Преемник ALGOL-60 
Развитие ALGOL-60 
Классы, абстрактные данные 


* В 1970—1980-е годы возникло множество языков, из которых лишь 
немногие доказали свою жизнеспособность. 

В каждом последующем поколении механизмы абстракции претерпевали 
изменения. Языки первого поколения ориентировались на научно-инженер¬ 
ные применения, и словарь предметной области был исключительно матема¬ 
тическим. Назначение таких языков, как FORTRAN I, состояло в упрощен¬ 
ном по сравнению с ассемблером или машинным кодом написанием матема¬ 
тических формул. Таким образом, первое поколение языков было шагом в 
направлении предметной области и отвлечением от особенностей компьютера. 
Во втором поколении языков основной тенденцией оказалось развитие алго¬ 
ритмических абстракций. В это же время существенно выросла вычислитель¬ 
ная мощность компьютеров и снизилась их стоимость, что позволило расши¬ 
рить область их применения, особенно в экономике. Главной задачей стала 
проблема ввода в машину инструкций: как считывать данные, сортировать 
их и выводить результаты на печать. Это был еще один шаг в направлении 
предметной области. В конце 60-х годов появление транзисторов, а затем 
интегральных схем резко снизило стоимость компьютеров, а их производи¬ 
тельность росла почти экспоненциально. Возникла возможность решать все 
более крупные задачи, но это требовало умения обрабатывать разнородные 
данные. С возможностью обработки абстрактных данных связано появление 
языка ALGOL-60 и затем языка Pascal. Программисты получили возмож- 
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ность описания разнообразных видов данных (типов) и обработки их с по¬ 
мощью этих языков. Это стало еще одним шагом в направлении приближе¬ 
ния к предметной области. 

В 70-х годах были созданы тысячи различных языков и диалектов. Не¬ 
адекватность более ранних языков задаче написания все более крупных про¬ 
граммных систем стала очевидной, поэтому новые языки имели механизмы 
устранения этого препятствия. Лишь часть из новых языков смогла выжить 
(уже трудно найти литературу по языкам Fred, Chaos, Tranquil), однако 
многие их принципы нашли отражение в новых версиях более ранних язы¬ 
ков. Таким образом, мы получили языки Ada (наследник ALGOL-68 и 
Pascal с элементами Simula, Alphard и CLU), CLOS (объединивший Lisp, 
LOOPS и Flavors) и C++ (возникший в результате слияния С и Simula). 
Наибольший интерес для дальнейшего изложения представляет класс языков, 
называемых объектными и объектно-ориентированными, которые в наиболь¬ 
шей степени отвечают задаче объектно-ориентированной декомпозиции. 

Архитектура языков программирования первого и второго поколения. 
Для пояснения сказанного следует рассмотреть каждое поколение языков с 
несколько иной точки зрения. На рис. 2-1 показана архитектура большинст¬ 
ва языков первого поколения и первой стадии второго поколения. Такая ар¬ 
хитектура отражает основные элементы конструкции языка программирова¬ 
ния и их взаимодействие. Можно отметить, что для таких языков, как 
FORTRAN и COBOL, основным элементом конструкции является подпрог¬ 
рамма (в нотации COBOL — параграф). Программы, реализованные на та¬ 
ких языках, имеют относительно простую структуру, состоящую из области 
глобальных данных и подпрограмм. Стрелками на рисунке обозначено воз¬ 
действие подпрограмм на различные данные. В процессе разработки про¬ 
грамм имеется возможность логического разделения разнотипных данных, но 
механизмы языков практически не поддерживают такого разделения. Ошибка 
в какой-либо части программы может иметь далеко идущие последствия, так 
как область данных является общей для всех подпрограмм. В больших сис¬ 
темах трудно гарантировать их целостность в процессе внесения изменений 
в какую-либо часть системы. В процессе эксплуатации уже через короткое 
время возникает путаница из-за большого количества перекрестных связей 
между подпрограммами, беспорядочности потоков управления, неопределенно¬ 
сти данных, что снижает надежность системы и достоверность результатов. 

Архитектура языков программирования второго и начальной стадии 
третьего поколения. Начиная с середины 60-х годов программы начали, на¬ 
конец, приобретать статус существенного промежуточного звена между реша¬ 
емой задачей и компьютером [3 ]. Шао отмечал: «Первая абстракция в про¬ 
граммном продукте, названная процедурой, прямо вытекает из традиционно¬ 
го взгляда на программные средства. Подпрограммы возникли до 1950 г., но 
тогда не были оценены в качестве абстракции. Они представлялись в виде 
средств, упрощающих работу. Но очень скоро стало ясно, что подпрограммы 
являются абстрактным отражением функций программного продукта» [4]. 


3 Гради Буч 
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Рис. 2-1. Архитектура языков программирования первого и начальной 
стадии второго поколения. 

Именно использование подпрограмм может служить механизмом абстра¬ 
гирования, имеющим три существенных следствия. Во-первых, в языках поя¬ 
вились механизмы, поддерживающие передачу параметров. Во-вторых, были 
заложены основания структурного программирования, отразившиеся в созда¬ 
нии механизмов вложения подпрограмм, включая ограничения области дей¬ 
ствия (видимости) компонентов. В-третьих, возникли методы структурного 
проектирования, обеспечивающие создание больших систем на основе под¬ 
программ. Понятно, что изменилась и архитектура языков программирования 
(рис. 2-2). Такая архитектура разрешила ряд противоречий, возникших в 
предыдущем периоде, в частности усилила управление алгоритмическими аб¬ 
стракциями, но не смогла решить задачу обеспечения программирования вы¬ 
сокого уровня и использования многообразия данных. 




Рис. 2-2. Архитектура языков программирования второго и начальной 
стадии третьего поколения. 
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Модули 



Рис. 2-3. Архитектура языков программирования третьего поколения 
(завершающая стадия). 

Архитектура языков программирования третьего поколения 
(завершающая стадия). Начиная с FORTRAN II и позднее для решения за¬ 
дач программирования на более высоком уровне стали возникать новые су¬ 
щественные механизмы структурирования. Создание больших проектов 
вызвало необходимость организации коллективной работы программистов, 
разрабатывающих параллельно отдельные части общей системы. 

Это привело к реализации механизма раздельной компиляции модулей, 
которые были чем-то большим, чем случайный набор данных и подпрограмм 
(рис. 2-3). Позднее модули стали важным механизмом абстракции, являясь 
вначале просто группой логически связанных подпрограмм. Для большинства 
языков этого поколения, использующих модульную структуру, слабо опреде¬ 
лены правила построения межмодульного интерфейса. Программист может 
предположить, что его подпрограмма будет вызываться с тремя параметрами: 
действительным числом, массивом из десяти элементов и целым числом, 
обозначающим булевский флаг управления. Вызов этой подпрограммы в дру¬ 
гом модуле может сопровождаться иными параметрами: целым числом, мас¬ 
сивом из пяти элементов и отрицательным числом. Поскольку средства под¬ 
держки абстракции данных и строгого типирования в таких языках недоста¬ 
точны, ошибка может быть выявлена только во время выполнения такой 
программы. 

Архитектура языков объектного и объектно-ориентированного програм¬ 
мирования. Значение абстрактных типов данных в разрешении проблемы 
сложности систем с очевидностью установлена Шанкаром: «Суть абстрагиро¬ 
вания, достигаемого посредством использования процедур, достаточна для 
описания абстрактных действий, но недостаточна для описания абстрактных 
объектов. Это серьезный недостаток, так как во многих практических ситуа- 
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циях сложность объектов, являющихся предметом управления, составляет ос¬ 
новную часть сложности всей задачи» [5]. Из этого вытекают два важных 
следствия. Во-первых, возникают методы проектирования управляемыми дан¬ 
ными, которые вносят порядок в обработку абстрактных данных алгоритми¬ 
ческими языками. Во-вторых, появляется теория типирования, которая воп¬ 
лощается в языках типа Pascal. 

Естественным завершением реализации этих идей, начавшейся с языка 
Simula и развитой в последующих языках в 1970—1980-е годы, стало появ¬ 
ление таких языков, как Smalltalk, Object Pascal, C++, CLOS и Ada. Имен¬ 
но эти языки получили название объектных или объектно-ориентированных. 
На рис. 2-4 приведена архитектура таких языков применительно к задачам 
малой и средней степени сложности. Основным элементом конструкции в 
указанных языках служит модуль, составленный из логически связанных 
классов и объектов, а не подпрограмма, как в языках первого поколения. 
Определим это следующим образом: «Если представить процедуры и функ¬ 
ции в виде глаголов, а данные в виде имен существительных, то процедур¬ 
ные программы строятся из глаголов, а объектно-ориентированные из имен 
существительных» [6]. По этой же причине структура программ малой и 
средней сложности при объектно-ориентированном подходе представляется 
графом, а не деревом, как в случае алгоритмических языков. Кроме того, 
сокращена или отсутствует область глобальных данных. Данные и действия 
организуются теперь таким образом, что основой конструкции становятся 
классы и объекты, а не алгоритмы. В настоящее время идет процесс, на¬ 
правленный на решение задач большой и глобальной степени сложности. 
Для достаточно больших систем классы, объекты и модули обнаруживают 
недостаточный уровень декомпозиции. 

К счастью, объектный подход может быть осуществлен на более высо¬ 
ких уровнях абстракций. Группы абстракций в больших системах могут 
представляться в виде многослойной структуры. На каждом уровне можно 
выделить группы объектов, тесно взаимодействующих для решения задачи 
более высокого уровня абстракции. Внутри каждой группы мы неизбежно 
найдем такое же множество взаимодействующих абстракций (рис. 2-5). Это 
соответствует подходу к сложным системам, изложенному в гл. 1. 

Основные положения объектного подхода 

Методы структурного проектирования имели своей целью упростить 
процесс разработки сложных систем на основе алгоритмического подхода. 
Методы объектно-ориентированного проектирования созданы в свою очередь 
для помощи разработчикам, использующим мощные выразительные средства 
объектного и объектно-ориентированного программирования, основанного на 
описании классов и объектов. В принципах объектного подхода нашли свое 
отражение и множество других факторов, кроме объектно-ориентированное 
программирование (OOP). Ниже показано, что объектный подход должен 
быть обобщенным подходом не только в программировании, но также в про¬ 
ектировании интерфейса пользователя, баз данных, баз знаний и даже ком¬ 
пьютерной архитектуры. Смысл такого широкого подхода состоит в том, что 
он позволяет применить объектную ориентацию для решения всего круга 
проблем, связанных со сложными системами. 
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Рис. 2-4. Архитектура программных систем малой и средней сложно¬ 
сти, использующих объектные и объектно-ориентированные языки про¬ 
граммирования. 

00D отражает эволюционный процесс в проектировании, а не револю¬ 
ционный; новая методология не является резким отходом от прежних мето¬ 
дов, а строится с учетом предшествующего опыта. К сожалению, большинст¬ 
во программистов в настоящее время используют формально или неформаль¬ 
но методы структурного проектирования. Разумеется, многие хорошие проек¬ 
тировщики создали и продолжают совершенствовать большое количество про¬ 
граммных систем на основе этой методологии. Однако трудно преодолеть ог¬ 
раничения, связанные с уровнем сложности таких систем, не прибегая к 
объектно-ориентированной декомпозиции. Более того, если мы попытаемся 
использовать такие языки, как C++ или Ada, в качестве традиционных ал¬ 
горитмических, мы не только потеряем их внутренний потенциал, скорее 
всего результат будет хуже, чем при использовании обычных языков С и 
Pascal. Дать мощную электродрель плотнику, который не слышал об элект¬ 
ричестве, значит использовать ее в качестве молотка. Но, прежде чем дрель 
превратится в негодный молоток, будет испорчено несколько гвоздей и раз¬ 
биты пальцы. 
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Рис. 2-5. Архитектура программных систем большой сложности на основе 
объектных и объектно-ориентированных языков программирования. 

OOP, OOD и ООА 

От множества своих предшественников объектный подход, к сожалению, 
унаследовал запутанную терминологию. Программирующие на Smalltalk поль¬ 
зуются термином «метод», на C++ — термином «фактическая функция-эле¬ 
мент», а в случае CLOS — «обобщенная функция». В Object Pascal исполь¬ 
зуется термин «приведение типов», а в языке Ada та же вещь называется 
«преобразованием типов». Чтобы избежать путаницы, следует определить бо¬ 
лее точно понятие объектной ориентации. Определения наиболее употребляе¬ 
мых терминов и понятий вы можете найти в словаре в конце книги. 

Термин «объектно-ориентированный», по мнению Бхаскара используется 
с легкой небрежностью теми, кто почтительно говорит «материнство», «кусок 
яблока» и «структурное программирование» [7]. Можно согласиться, что по¬ 
нятие объекта является центральным во всем, что относится к объектно-ори¬ 
ентированной методологии. В гл. 1 мы определили объект как осязаемую 
сущность, которая четко проявляет свое поведение. Стефик и Бобров опре¬ 
деляют объекты как «нечто, объединяющее свойства процедур и данных в 
процессе выполнения вычислений и сохраняющее локальное состояние» [8]. 
Такое определение объекта допустимо, но главным в понятии объекта явля¬ 
ется все же объединение идей абстрагирования данных и алгоритмов. Джонс 
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уточняет это понятие следующим образом: «В объектном подходе акцент 
переносится на конкретные характеристики физической и абстрактной систе¬ 
мы, являющейся предметом программного моделирования... Объекты облада¬ 
ют целостностью, которую не следует нарушать. Объект может только ме¬ 
нять состояние, поведение, управляться или становиться в определенное от¬ 
ношение к другим объектам. Объект обладает неизменными качествами, но 
может изменять свое состояние. Например, подъемник характеризуется тем, 
что может двигаться вверх и вниз, оставаясь в пределах своих направляю¬ 
щих ... Любая модель должна учитывать эти свойства подъемника, так как 
они составляют его назначение» [32]. 

Объектно-ориентированное программирование. Объектно-ориентирован¬ 
ные программирование — это методология программирования, которая ос¬ 
нована на представлении программы в виде совокупности объектов, каж¬ 
дый из которых является реализацией определенного класса, а классы об¬ 
разуют иерархию на принципах наследуемости. 

В данном определении можно выделить три части: 1) OOP использует в 
качестве элементов конструкции объекты, а не алгоритмы (иерархия по со¬ 
ставу была определена в гл. 1); 2) каждый объект является реализацией ка¬ 
кого-либо определенного класса; 3) классы организованы иерархически 
(иерархия по номенклатуре обсуждена в гл. 1). Программа будет объектно- 
ориентированной только при соблюдении всех трех, указанных требований. В 
частности, программирование не основанное на иерархических отношениях, 
не относится к OOP, а называется программированием на основе абстракт¬ 
ных типов данных. 

Исходя из этого, ясно, что не все языки программирования являются 
объектно-ориентированными. Страустрап определил так: «если термин «объ¬ 
ектно-ориентированный язык» что-то означает, то он должен означать язык, 
имеющий все необходимые средства для обеспечения объектно-ориентирован¬ 
ного стиля программирования ... Обеспечение такого стиля в свою очередь 
означает наличие соглашений по реализации стиля программирования. Если 
написание программ в стиле OOP требует специальных усилий или оно не¬ 
возможно совсем, то этот язык не отвечает требованиям ООР» [33]. Теоре¬ 
тически возможна имитация объектно-ориентированного программирования на 
обычных языках, таких, как Pascal и даже COBOL или ассемблер, но это 
крайне затруднительно. Карделли и Вагнер утверждают: «язык программиро¬ 
вания является объектно-ориентированным тогда и только тогда, когда вы¬ 
полняются следующие условия: 

* Имеется поддержка объектов в виде абстракции данных имеющих интер¬ 
фейсную часть в виде поименованных операций и защищенную область 
локальных данных. 

* Объекты относятся к соответствующим типам (классам). 

* Типы (классы) могут наследовать атрибуты от супертипов (суперклас¬ 
сов)» [34]. 
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Основные положения объектного подхода 

Юнизава и Токоро свидетельствуют, что «термин «объект» появился 
практически независимо в различных областях, связанных с компьютери¬ 
зацией, и почти одновременно в начале 70-х годов для обозначения того, 
что может иметь различные проявления, оставаясь целостным. Это требо¬ 
валось для того, чтобы уменьшить сложность программных систем, обоз¬ 
начая объектами компоненты системы или фрагменты представляемых 
знаний» [9 ]. По мнению Леви, объектно-ориентированный подход был 
связан со следующими событиями [10]: 

* «Прогресс в области архитектуры ЭВМ, включая системную и аппарат¬ 
ную поддержку. 

* Развитие языков программирования, таких, как Simula, Smalltalk, CLU, 
Ada. 

* Развитие методологии программирования, включая принципы модульно¬ 
сти и защиты информации». 

К этому еще следует добавить три момента, оказавшие влияние на 
становление объектного подхода: 

* Развитие баз данных. 

* Исследования в области искусственного интеллекта. 

* Достижения философии и теории познания. 

Понятие «объект» впервые было использовано более 20 лет назад в 
технических средствах при создании архитектур, основанных на описани¬ 
ях и реализациях [11]. В этих работах делались попытки отойти от тра¬ 
диционной архитектуры Неймана и преодолеть барьер между высоким 
уровнем программных абстракций и низким уровнем абстрагирования на 
уровне ЭВМ [12]. При этом были созданы более качественные средства: 
лучшее выявление ошибок, большая эффективность реализации программ, 
сокращен набор команд, упрощена компиляция, снижены объемы требуе¬ 
мой памяти. Ряд компьютеров имеет объектно-ориентированную архитек¬ 
туру: Burronghs 5000, Plessey 250, Cambridge CAP [13], SWARD [14], 
Intel 432 [15], Caltech’s COM [16], IBM System/38 [17], Rational R1000, 
BiiN 40 и 60. 

С объектно-ориентированной архитектурой тесно связаны объектно- 
ориентированные операционные системы (ОС). Дейкстра, работая над 
мультипрограммной системой THE, впервые ввел понятие структурирован¬ 
ной машины состояний в качестве средства реализации систем [18]. Сре¬ 
ди первых объектно-ориентированных ОС следует отметить: 
Plessey/System 250 (для мультипроцессора Plessey 250), Hydra (для CMU 
c.mmp), CALTSS (для CDC 6400), САР (для Cambridge CAP), UCLA 
Secure Unix (для PDP 11/45 и 11/70), StarOS (для CMU Cm*), Medusa 
(также для CMU Cm*) и iMAX (для Intel 432) [19]. 

Наиболее значительный вклад в объектный подход внесен объектны¬ 
ми и объектно-ориентированными языками программирования. Впервые 
понятия классов и объектов введены в языке Simula 67. Система Flex и 
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последовавшие за ней диалекты Smalltalk-72, -74, -76 и, наконец, -80, 
взяв за основу методы Simula, довели их до логического завершения, вы¬ 
полняя все действия на основе классов. В 1970-х годах создан ряд язы¬ 
ков, реализующих идеи абстрактных данных: Alphard, CLU, Euclid, 
Gypsy, Mesa и Modula. Затем методы, используемые в языках Simula и 
Smalltalk, были использованы в традиционных языках высокого уровня. 
Внесение объектно-ориентированного подхода в С привело к возникнове¬ 
нию языков C++ и Objective С. На основе языка Pascal возникли Object 
Pascal, Eiffel и Ada. Появились диалекты LISP, такие, как Flavors, 
LOOPS и CLOS (common LISP Object System), с возможностями языков 
Simula и Smalltalk. Более подробно особенности этих языков изложены в 
приложении. Первым, кто указал на необходимость построения систем в 
виде структурированных абстракций, был Дейкстра. Позднее Парнас ввел 
идею защиты информации [20], а в 70-х годах ряд исследователей раз¬ 
работали механизмы абстрактных типов данных [21-23], Хоар дополнил 
эти подходы теорией типов и подклассов [24]. 

Развивавшиеся достаточно независимо технологии построения баз 
данных также оказали влияние на объектный подход [25] в первую оче¬ 
редь благодаря идеям отношений сущности (ER) в моделировании баз 
данных [26]. В моделях ER, впервые изложенных Ченом [27], задачи 
представляются в терминах сущностей, их атрибутов и взаимоотношений. 
Разработчики способов представления данных в области искусственного 
интеллекта также внесли свой вклад в понимание объектно-ориентирован¬ 
ных абстракций. В 1975 г. Мински выдвинул теорию фреймов для пред¬ 
ставления реальных объектов в системах распознавания образов и естест¬ 
венных языков [28 ]. Фреймы стали использоваться в качестве архитек¬ 
турной основы в различных интеллектуальных системах. Объектный под¬ 
ход известен еще издавна. Грекам принадлежит идея о том, что мир 
можно рассматривать как в терминах объектов, так и событий. А в 17 в. 
Декарт отмечал, что люди обычно имеют объектно-ориентированный 
взгляд на мир [29]. В 20 в. эту тему развивала Ранд в своей теории 
познания [30]. Позднее Мински предложил модель человеческого мышле¬ 
ния, в которой разум человека рассматривается как общность различно 
мыслящих агентов [31 ]. Он доказывает, что только совместное действие 
таких агентов приводит к осмысленному поведению человека. 


Поддержка наследуемости в таких языках означает возможность уста¬ 
новления отношений вида «разновидность» между типами, например красная 
роза — разновидность цветов, а цветок — разновидность растений. Языки, 
не имеющие таких механизмов, нельзя отнести к объектно-ориентированным. 
Карделли и Вагнер назвали такие языки объектными, но не объектно-ориен¬ 
тированными. Исходя из этого, объектно-ориентированными языками являют¬ 
ся Smalltalk, Object Pascal, C++ и CLOS, a Ada — объектный язык. Но, по¬ 
скольку объекты и классы являются элементами обеих групп языков, мето¬ 
ды OOD желательно использовать и в тех и в других. 
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Объектно-ориентированное проектирование. Методы программирования 
прежде всего подразумевают правильное и эффективное использование меха¬ 
низмов языков программирования. Методы проектирования, напротив, основ¬ 
ное внимание направляют на правильное и эффективное структурирование 
сложных систем. 

Определим объектно-ориентированное проектирование следующим обра¬ 
зом: 

Объектно-ориентированное проектирование — это методология проек¬ 
тирования, соединяющая в себе процесс объектной декомпозиции и приемы 
представления как логической и физической, так статической и динамиче¬ 
ской моделей проектируемой системы. 

В данном определении содержатся две важные части: 1) OOD ведет к 
объектно-ориентированной декомпозиции; 2) используется многообразие при¬ 
емов представления моделей, отражающих логическую (структуры классов и 
объектов) и физическую (архитектура моделей и процессов) структуру сис¬ 
темы. 

Именно поддержка объектно-ориентированной декомпозиции отличает 
OOD от структурного проектирования; в первом случае логическая структура 
системы отражается абстракциями в виде классов и объектов, во втором в 
виде алгоритмического обозначения методов, связанных с объектно-ориенти¬ 
рованной декомпозицией. 

Объектно-ориентированный анализ. На объектный подход оказали влия¬ 
ние предыдущие этапы развития программных средств. Традиционные при¬ 
емы структурного анализа, известные по работам Де Марко [35], Йорда¬ 
на [36], Гане и Сарсона [37], с уточнениями для режимов реального вре¬ 
мени Варда и Меллора [38], Хатли и Пирбой [39] основаны на потоках 
данных в системе. 

Объектно-ориентированный анализ (ООА) направлен на создание моде¬ 
лей, более близких к реальности, с использованием объектно-ориентирован¬ 
ного подхода; это методология, при которой требования формируются на 
основе понятий классов и объектов, составляющих словарь предметной 
области. 

На результатах ООА формируются модели, на которых основывается 
OOD; OOD в свою очередь создает основу для окончательной реализации 
системы с использованием методологии OOP. 

2.2. КОМПОНЕНТЫ ОБЪЕКТНОГО ПОДХОДА 
Способы программирования 

Дженкинс и Глазгов считают, что «большинство программистов исполь¬ 
зуют в работе один язык программирования и один стиль. Приемы и спосо¬ 
бы программирования определяются используемым языком. Часто в стороне 
остаются альтернативные подходы к цели, а следовательно, не используются 
оптимальные решения в выборе стиля, соответствующего решаемой зада 
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че» [40 ]. Бобров и Стефик так определили понятие стиля программирова¬ 
ния: «Это способ построения программ, основанный на определенных прин¬ 
ципах программирования и выборе языка, с целью добиться ясности понима¬ 
ния программы» [41 ]. Эти же авторы выявили пять основных разновидно¬ 
стей стиля программирования, которые перечислены ниже вместе с присущи¬ 
ми им видами абстракций: 


* Процедурно-ориентированный 

* Объектно-ориентированный 

* Логически-ориентированный 

* Ориентированный на правила 

* Ориентированный на ограничения 


Алгоритмы 
Классы и объекты 

Цели, наиболее часто выраженные в 
исчислениях предикатов 
Правила «если...то» 

Инвариантные соотношения 


Невозможно назвать какой-либо стиль программирования наилучшим во 
всех областях практического применения. Например, для проектирования баз 
знаний более пригоден стиль, ориентированный на правила. Рассматривае¬ 
мый нами объектно-ориентированный стиль является наиболее приемлемым 
для широкого круга задач, связанных с большими промышленными систе¬ 
мами, в которых основной проблемой является сложность. 

Каждый стиль программирования имеет свою концептуальную основу, 
требует различного подхода к решаемой задаче. Для объектно-ориентирован¬ 
ного стиля концептуальная основа состоит в объектном подходе. Этому под¬ 
ходу соответствуют четыре главных элемента: 

* Абстрагирование. 

* Ограничение доступа. 

* Модульность. 

* Иерархия. 

Эти элементы являются главными в том смысле, что без любого из 
них подход не будет объектно-ориентированным. Кроме главных имеется 
еще три дополнительных элемента: 

* Типизация. 

* Параллелизм. 

* Устойчивость. 

Эти элементы являются полезными, но не обязательными в объектном 
подходе. Отсутствие соответствующей концептуальной основы приведет к то¬ 
му, что программы, написанные на языках Smalltalk, Object Pascal, C++, 
CLOS и Ada, будут мало отличаться от программ на FORTRAN, PASCAL 
или С. Выразительная способность этих объектных или объектно-ориентиро¬ 
ванных языков будет либо потеряна, либо искажена. Но еще более сущест¬ 
венно, что при этом будет мало шансов «справиться» со сложностью решае¬ 
мых задач. 

Абстрагирование 

Роль абстрагирования. Абстрагирование является одним из главных спо¬ 
собов, используемых для решения сложных задач. Хоаре предположил, что 
«абстрагирование заключается в нахождении сходств между определенной со- 
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вокупностью объектов, ситуаций или процессов, имеющих место в реально¬ 
сти, и в принятии решений на основе этих сходств, отвлекаясь на время от 
имеющихся отличий между этими объектами» [42]. Шоу определил это по¬ 
нятие так: «Упрощенное описание или изложение системы, при котором 
одни свойства и детали выделяются, а другие опускаются. Хорошей является 
такая абстракция, при которой подчеркиваются существенные для рассмотре¬ 
ния и использования детали и опускаются те, которые на данный момент 
несущественны или отвлекают внимание» [43]. Берзине, Грей и Науман до¬ 
бавили к этому следующее: «Абстракцией является только такая идея, кото¬ 
рая может быть изложена, понята и проанализирована независимо от меха¬ 
низма ее реализации» [44]. Суммируя все изложенное, получим следующее 
определение абстракции: 

Абстракция — это такие существенные характеристики некоторого 
объекта, которые отличают его от всех других видов объектов и, таким 
образом, четко определяют особенности данного объекта с точки зрения 
дальнейшего рассмотрения и анализа. 

Абстрагирование концентрирует внимание на внешних особенностях объ¬ 
екта и позволяет отделить самые существенные особенности поведения от 
деталей их осуществления. Абельсон и Суссман назвали такое разделение 
(поведение от осуществления) барьером абстракции [45], который основыва¬ 
ется на принципе минимизации связей, когда интерфейс объекта содержит 
только существенные аспекты поведения [46]. Полезным является еще один 
дополнительный принцип, называемый принципом наименьшей выразительно¬ 
сти, по которому абстракция должна охватывать лишь самую суть объекта, 
не больше, но и не меньше. Выбор достаточного множества абстракций для 
заданной предметной области является главной проблемой объектно-ориенти¬ 
рованного проектирования. Гл. 4 целиком посвящена этой теме. По мнению 
Сейдевитца и Старка, «существует целый спектр абстракций, начиная с объ¬ 
ектов, которые приблизительно соответствуют сущности предметной области, 
кончая объектами, не имеющими реальных аналогий в жизни» [47]: 


* Абстракция сущности объекта 

* Абстракция поведения 

* Абстрагирование в виде вир¬ 
туальной машины 


* Произвольная абстракция 


Объект представляет собой модель сущест¬ 
венных сторон предметной области 
Объект состоит из обобщенного множества 
операций, каждая из которых выполняет 
определенную функцию 
Объект объединяет группы операций вир¬ 
туальной машины, которые используются 
либо для управления объектом, либо соот¬ 
ветствуют функциям нижнего уровня 
Объект включает в себя набор независи¬ 
мых по отношению друг к другу операций 


Наиболее интересны для нас абстракции сущности объектов, так как 
они соответствуют словарю предметной области. Объект, использующий ре¬ 
сурсы других объектов, называется клиентом. Описание поведения объекта 
включает описание операций, которые могут выполняться над ним, и опера¬ 
ций, которые сам объект выполняет над другими объектами. Такой подход 
концентрирует внимание на внешних особенностях объекта. Полный набор 
операций, которые объект может осуществлять над другим объектом, назы¬ 
вается протоколом. Протокол отражает все действия, которым объект может 
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подвергаться сам и которыми может оказывать влияние на другие объекты, 
определяя тем самым полностью внешнее повеление абстракции со статиче¬ 
ской и динамической точек зрения. 

Заметим, что понятия операция, метод и функция — элемент 
(operation, method, member function) происходят от различных традиций про¬ 
граммирования (Ada, Smalltalk и C++ соответственно). Фактически они обоз¬ 
начают одно и то же и в дальнейшем будут использоваться эквиваленты. 

Все абстракции обладают как статическими, так и динамическими свой¬ 
ствами. Например, объект-файл требует определенного объема памяти, имеет 
имя и содержание. Эти атрибуты являются статическими. Конкретные значе¬ 
ния каждого из перечисленных свойств являются динамическими, изменяю¬ 
щимися в процессе использования объекта: файл может изменять свои раз¬ 
меры, имя и содержимое. В процедурном стиле программирования изменения 
динамических характеристик объектов составляют суть программ. Любые со¬ 
бытия связаны с вызовом подпрограмм и с выполнением операторов. Стиль 
программирования, ориентированный на правила, характеризуется тем, что 
под влиянием определенных условий активизируются определенные правила, 
которые в свою очередь возбуждают другие правила и так далее. Объектно- 
ориентированный стиль программирования связан с воздействием на объекты 
(в языке Smalltalk объектам передают сообщения). Путем воздействия на 
объект вызывается определенная реакция этого объекта. Операции, которые 
можно выполнить по отношению к данному объекту, и реакция объекта на 
внешние воздействия составляют характер поведения этого объекта. 



Абстрагирование позволяет сосредоточить внимание на существенных ха¬ 
рактеристиках объекта с точки зрения наблюдателя. 
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Примеры абстракций. Для иллюстрации сказанного выше приведем не¬ 
сколько примеров. В данном случае мы сконцентрируем внимание не столь¬ 
ко на том, как формируются абстракции для конкретной задачи (это под¬ 
робно рассмотрено в гл. 4), сколько на способе выражения абстракций. 

В тепличном хозяйстве, использующем гидропонику, растения выращи¬ 
ваются на питательном растворе без песка, гравия или другой почвы. Уп¬ 
равление режимом работы такого хозяйства очень серьезная и «тонкая» про¬ 
блема, зависящая как от вида выращиваемых культур, так и от стадии вы¬ 
ращивания. При этом нужно контролировать целый ряд таких факторов, 
как температура, влажность, освещение, кислотность (показатель pH) и кон¬ 
центрация питательных веществ. В больших хозяйствах для решения этой 
задачи часто используют автоматические системы, которые контролируют и 
регулируют указанные факторы. Попросту говоря, цель автоматизации состо¬ 
ит здесь в том, чтобы при минимальном вмешательстве человека добиться 
соблюдения плана-графика выращивания хорошего урожая. 

Одной из ключевых абстракций в такой задаче является датчик. 
Известно несколько разновидностей датчиков. Все важные воздействующие 
факторы должны быть измерены. Для этого существуют датчики температу¬ 
ры, влажности, pH, освещения и концентрации питательных веществ. С 
внешней точки зрения датчик температуры — это объект, который способен 
измерять температуру в определенном месте. Что такое температура? Это 
числовой параметр, имеющий ограниченный диапазон значений и определен¬ 
ную точность, означающий число градусов по Фаренгейту, Цельсию или 
Кельвину в зависимости от условий конкретной задачи. Что такое местопо¬ 
ложение датчика? Это определенное указанное место в теплице, в котором 
нам необходимо знать температуру; таких мест, вероятно, несколько. Для 
датчика температуры существенно не столько само местоположение, сколько 
тот факт, что данный датчик расположен именно в данном месте и что от¬ 
личает его от других датчиков. Теперь можно задать вопрос о том, какие 
действия можно выполнять по отношению к датчику? В нашем случае поль¬ 
зователь может калибровать датчик и получать от него значение текущей 
температуры. 

Для демонстрации проектных решений ниже приводятся примеры на 
языке Ada. Читатели недостаточно знакомые с этим языком, а также 
желающие уточнить свои знания по другим объектным и объектно-ориенти¬ 
рованным языкам, упоминаемым в этой книге, могут найти их краткие опи¬ 
сания с примерами в приложении. На языке Ada абстрактное описание дат¬ 
чика температуры воздуха будет отражено следующей спецификацией: 
package Temperature_Scnsors is 

type Temperature is delta 0.01 range -Ю.О.. 150.0; 

— temperature in degrees Fahrenheit 

type location is range 0..63; 

— a number denoting the location of a sensor 

type Air_Temperature_Sensor is limited private; 

— the air temperature sensor class 
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procedure Initialize (The_Sensor : in Air_Temperature_Sensor; 

Its_Location : in Location ); 

procedure Calibrate (The_Sensor : in out Air_Temperature_Sensor; 

Actual_Temperature : in Temperature); 

function Current_Temperature (The_Sensor : in Air_Temperature_Sensor ) 
return Tempetature; 

end Temperature_Sensor; 

Этот модуль определяет (экспортирует) три типа данных: Temperature, 
Location и Air_Temperature_Sensor. Тип Temperature представляется числом с 
фиксированной точкой, означающим температуру по Фаренгейту. Тип 
Location обозначает вариант размещения датчика. Наконец, тип 
Air_Temperature_Sensor составляет собственно абстракцию датчика, представ¬ 
ление которой выполнено защищенным. 

Поскольку приведенное описание является описанием класса, прежде 
чем выполнить какие-либо действия, необходимо создать экземпляр объекта 
(реализацию) данного класса, например, следующим образом: 

with Temperature_Sensor; 
use Temperature_Sensor; 

Greenhouse_l_Temperature_Sensor : Air_Temperature_Sensor; 
Greenhouse_2_Tempcrature_Sensor : Air_Temperature_Sensor; 

The_Temperature : Temperature; 

begin 

Initialize(Greenhouse_l_Temperature_Sensor, Its_Location -> 1); 
Initialize(Grcenhouse_2_Temperature_Sensor, Its_Location -> 2); 

The_Temperature Current_Tempcrature (Greenhouse_l_Temperature_Sensor); 


Описанная абстракция является пассивной; другие объекты могут воз¬ 
действовать на этот объект (датчик температуры), чтобы получить его зна¬ 
чение. Описание объекта температурного датчика можно сделать и актив¬ 
ным, чтобы он воздействовал на другие объекты в случае, если измеряемая 
температура изменится на некоторое число градусов. Такая абстракция будет 
похожа на предыдущую, но ее интерфейс становится двухсторонним, и бу¬ 
дет выглядеть следующим образом: 

package Tempcraturc_Sensors is 

type Temperature is delta 0.01 range -Ю.О.. 150.0; 

— temperature in degrees Fahrenheit 


type Location is range 0..63; 

— a number denoting the location of a sensor 

with procedure Temperature_Has_Changed 
with procedure Tcmperature_Alarm 
package Temperature_Sensors is 


(The_Location : in Location; 
New_Temperature : in Temperature); 
(The_Location : in Location; 
New_Temperature ; in Temperature); 





48 


Концепции 


type Air_Temperature_Sensor is limited private; 

— the air temperation sensor class 

in Air_Temperature_Sensor; 
in Location; 
in Temperature; 
in Temperature); 
in out Air_Temperature_Sensor; 
in Tempetature); 

end Air_Temperature_Sensors; 
end Temperature_Sensore; 


procedure initialize une_sensor 
Its_Location 
Lower_Alarm_Limit 
Upper_Alarm_Limit 
procedure Calibrate (The_Sensor 

Actual Temperature 


Такое описание сложнее первого, но более полно соответствует описы¬ 
ваемой абстракции. Над указанным объектом можно выполнять только две 
операции: инициализацию и калибровку. В процессе существования каждый 
из объектов типа датчика температуры имеет возможность формировать со¬ 
общения об изменении температуры и аварийной ситуации для передачи в 
другие объекты. На данном примере, таким образом, показано использование 
языка Ada для описания действий над объектом и выполнения воздействий 
самого объекта на другие объекты. 

Рассмотрим другой пример абстракции, на языке C++. В тепличном хо¬ 
зяйстве с целью обеспечения наибольшего урожая необходим план выращи¬ 
вания, учитывающий влияние факторов температуры, освещения, вносимых 
питательных веществ и ряда других на выращивание культур. Поскольку 
такой план является частью словаря предметной области, вполне оправданна 
его реализация в виде абстракции. 

Для каждой выращиваемой культуры существует отдельный такой план, 
но общая форма планов во всех случаях одинакова. Основу плана выращи¬ 
вания составляет таблица, отражающая во времени перечень необходимых 
действий. Например, для некоторой культуры на 15-е сутки ее роста план 
предусматривает поддержание в течении 16 ч температуры 78’ F, из них 
15 ч с освещением, а затем понижение температуры до 65’ F на остальное 
время суток. Кроме того, может потребоваться внесение определенного веще¬ 
ства для поддержания заданной кислотности в почве (показатель pH). 

С точки зрения интерфейса объекта-плана необходимо обеспечить воз¬ 
можность задания деталей плана, изменять план и осуществлять его выпол¬ 
нение. Например, возможно наличие объекта, обеспечивающего интерфейс 
человек-компьютер и ручное изменение плана. Это означает внесение изме¬ 
нений в объект-план с целью корректировки отдельных деталей. Кроме того, 
должен существовать объект-исполнитель плана, имеющий возможность чи¬ 
тать данные о плане. Как видно из дальнейшего описания, ни один объект 
не обособлен, а все они взаимодействуют для обеспечения общей цели. Ис¬ 
ходя из такого подхода, определяются и граница каждого объекта-абстрак¬ 
ции, и протоколы их связи. 
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Реализация плана выращивания на языке C++ будет выглядеть следую¬ 
щим образом: 

typedef int day, 
typedef int hour; 
typedef float temperature; 
typedef float ph; 
typedef float concentration; 
enum boolean (OFF, ON) ; 

class GrowingPlan { 



GrowingPlan (); 

GrowingPlan (count GrowingPlan*); 
virtual -GrowingPlan 0; 

virtual void clearThePlan 0; 

virtual void establish (day theDay, 

hour IheHour, 

temperature theTemperature, 

boolean lightsOn, 

ph thePh, 

concentration theNutrientConcentration); 

virtual temperature desiredTemperature (day theDay, hour IheHour) const; 

virtual boolean linghtStatus (day theDay, hour theHour) const; 

virtual ph desiredPh (day theDay, hour theHour) const; 

virtual concentration desiredNutrients (day theDay, hour theHour) const; 



Ограничение доступа позволяет скрыть детали устройства объекта. 

Гради Буч 
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Поясним использование в этом примере определения типов. Стиль про¬ 
граммирования требует явного объявления всех типов, составляющих словарь 
предметной области, если это не противоречит другим обстоятельствам. Ин¬ 
терфейс объекта-плана выращивания намеренно лишен обособленных состав¬ 
ляющих, чтобы сосредоточить внимание на поведении объекта, а не на осо¬ 
бенностях его строения. В языке C++ обособленными являются все элементы 
описания, если явно не определено другое. 

В общедоступную часть описания (public) вынесены конструктор и де¬ 
структор объекта (определяющие процедуры порождения и уничтожения 
данного объекта), две процедуры модификации (очистка всего плана и опре¬ 
деление элементов плана) и четыре селектора-определителя состояния (по 
одному для каждого элемента состояния плана выращивания) плана на дан¬ 
ный момент. Стиль программирования подразумевает определение всех фун¬ 
кций-элементов объекта в качестве фактических (virtual), чтобы сохранить 
возможность их переопределения в подклассах (если по другим причинам не 
требуется иного). 

Так же как в случае примера на языке Ada, класс план-выращивания 
является абстракцией, а не объектом, пригодным для использования. Поэто¬ 
му требуется в каком-то определенном месте программы создать экземпляр 
объекта данного класса и использовать его затем для соответствующих ма¬ 
нипуляций. 

Ограничение доступа 

Понятие органичения доступа. Созданию абстракции какого-либо объек¬ 
та должны предшествовать определенные решения о способе ее реализации. 
Выбранный способ реализации должен быть скрыт и защищен для большин¬ 
ства объектов-пользователей (обращающихся к данной абстракции). Как 
справедливо отметил Ингалс, «никакая часть сложной системы не должна 
находиться в зависимости от подробностей внутреннего устройства других 
частей системы» [48]. Ограничение доступа «позволяет вносить в программу 
изменения, сохраняя ее надежность и минимизируя затраты на этот про¬ 
цесс» [49]. 

Абстрагирование и ограничение доступа являются взаимодополняющими 
операциями: абстрагирование фокусирует внимание на внешних особенностях 
объекта, а ограничение доступа — или иначе защита информации — не 
позволяет обьектам-пользователям различать внутреннее устройство объекта. 
Ограничение доступа, таким образом, определяет явные барьеры между раз¬ 
личными абстракциями. Возьмем для примера структуру растения: чтобы по¬ 
нять на верхнем уровне действие фотосинтеза, вполне допустимо игнориро¬ 
вать такие подробности, как корни растения или метахондрии клеток. Ана¬ 
логичным образом при проектировании баз данных программисты не обраща¬ 
ют внимание на физический смысл данных, а сосредоточиваются на схеме, 
отражающей логическое строение данных [50]. 

В обоих случаях объекты верхнего уровня абстракции не связаны прямо 
с подробностями их реализации на низком уровне. Лисков считает что «для 
«работы» абстракции, доступ к ее внутренней структуре должен быть огра¬ 
ничен» [51 ]. Практически это означает наличие двух частей в описании 
класса: интерфейса и реализации. Интерфейс отражает внешнее проявление 
объекта, создавая абстракцию поведения всех объектов данного класса. Внут¬ 
ренняя реализация описывает механизмы достижения желаемого поведения 
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объекта. Принцип такого различения интерфейса и реализации соответствует 
разделению по сути: в интерфейсной части собрано все, что касается взаи¬ 
модействия данного объекта с любыми другими объектами; реализация 
скрывает от других объектов все детали, не имеющие отношения к процессу 
взаимодействия объектов. Бриттон и Парнас назвали такие подробности 
«тайнами» абстракции [52]. 

Итак, понятие ограничения доступа можно определить следующим обра¬ 
зом: 

Ограничение доступа — это процесс защиты отдельных элементов 
объекта, не затрагивающий существенных характеристик объекта как це¬ 
лого. 

На практике осуществляется защита как структуры объекта, так и реа¬ 
лизации его методов. 

Примеры использования ограничения доступа. Для иллюстрации прак¬ 
тического использования ограничения доступа вернемся к примеру теплично¬ 
го хозяйства. Одной из ключевых абстракций данной предметной области 
является абстракция обогревателя, поддерживающего заданную температуру в 
помещении. Обогреватель является абстракцией низкого уровня, поэтому 
можно предположить достаточным выполнение над этим объектом всего трех 
действий: включения, выключения и проверки работоспособности. В соответ¬ 
ствии с принятым стилем описания должны быть также определены опера¬ 
ции создания и ликвидации объектов — конструктор и деструктор. Реальная 
система может содержать множество обогревателей, поэтому для привязки 
конкретного объекта программы к физическому обогревателю необходима 
процедура (метод) инициализации. С учетом сказанного можно описать на 
языке Smalltalk интерфейс объекта-обогревателя следующим образом: 

Heater methodsFor: ’initlalize-release’ 
initialize: theLocation 
realise 

Heater methodsFor: 'modifiers’ 

turnOff 

turnOn 

Heater.methodsFor: 'selectors’ 
isOn 

Такое описание интерфейса в совокупности с пояснительной документа¬ 
цией на каждый из операторов интерфейса представляет все необходимое, 
что требуется для взаимодействия с любыми другими объектами программы. 

Иначе обстоит дело с внутренним содержанием объекта-обогревателя. 
Вполне понятно, что для подключения обогревателя в сеть требуется элект¬ 
ромеханическое реле, которое в свою очередь управляется сигналом, посту¬ 
пающим от компьютера через параллельный порт. Для включения обогрева¬ 
теля используется посылка байта, все разряды которого установлены в «1», 
а для отключения в «О». Исходя из этого, получим следующее описание ре¬ 
ализации объекта-обогревателя: 

Object subclass: «Heater 

instanceVariableNames: ’thePort isOn’ 



52 


Концепции 


dassVariableNames: ’ ’ 
pcolDictionaries: ’ ’ 

category: ’Hydroponics Gardening System' 

Initialize: theLocation 

«Initialize the heater device driver by opening an RS232 port associated with the given location, 
theLocation is expected to be of the class Location.» 
thePort <— RS232Port open: theLocation. 
isOn <— false 

release 

«Release the RS232 port associated with this heater.» 
thePort release. 
thePort <— nil 

isOn 

«Return true if heater is on, false otherwise.» 

^isOn 

turnOff 

«Turn off the heater by writing a character with all bits reset to the RS232 port.» 

I aString I 

aString <— String new: 1. 

aString at: 1 put: (Character value: 0). 

thePort sendBuffer: aString. 

isOn <— false. 

aString release 

turnOn 

«Turn on the heater by writing a character with all bits reset to the RS232 port.» 

I aString I 

aString <— String new: 1. 

aString at: 1 put: (Character value: 255). 

thePort sendBuffer: aString. 

isOn <— false. 

aString release 

В соответствии с правилами Smalltalk две переменные (thePort и isOn) 
размещены с учетом ограничения к ним доступа. Если программист сделает 
попытку обратиться к этим переменным вне указанного класса, возникнет 
сообщение об ошибке. 

Предположим, что по какой-либо причине изменилась архитектура ап¬ 
паратных средств системы и вместо последовательного порта управление дол¬ 
жно осуществляться через область памяти. В такой ситуации нет необходи¬ 
мости изменять интерфейсную часть объекта, а достаточно переписать реа¬ 
лизацию. Поскольку правила Smalltalk являются достаточно устаревшими, 
придется заново осуществить компиляцию измененного класса и других объ¬ 
ектов, так как их поведение не изменяется, если только эти другие объекты 
не зависят от временных и пространственных характеристик прежнего кода 
(что крайне нежелательно и совершенно не нужно). При правильном ис¬ 
пользовании ограничение доступа позволяет локализовать те особенности 
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проекта, которые подвержены изменениям. По мере развития системы может 
оказаться, что какие-то операции выполняются несколько дольше, чем допу¬ 
стимо, а какие-то объекты занимают больше памяти, чем приемлемо. В та¬ 
ких ситуациях часто изменяют структуру объекта, чтобы реализовать более 
эффективные алгоритмы или оптимизировать объемы используемой памяти. 
Важным преимуществом ограничения доступа является возможность внесения 
изменений в объект без изменения других объектов, связанных с данными. 

В идеальном случае попытки обращения к данным, закрытым для до¬ 
ступа, должны выявляться во время компиляции программы. Вопрос реали¬ 
зации этих условий для конкретных языков программирования является 
предметом постоянных обсуждений. Мы уже видим, что Smalltalk обеспечи¬ 
вает защиту от прямого доступа к переменным другого класса, обнаруживая 
такие попытки во время компиляции. В тоже время Object Pascal такой 
возможности не предоставляет. Язык CLOS «занимает* в этом вопросе про¬ 
межуточную позицию, возлагая все обязанности по ограничению доступа на 
программиста. В этом языке все слоты могут сопровождаться атрибутами, 
разрешающими чтение, запись и доступ к данным (в последнем случае чте¬ 
ние и запись). При отсутствии всех атрибутов слот является полностью за¬ 
щищенным от доступа. В языке C++ управление доступом и видимостью 
достигается с большей гибкостью. Элементы объекта могут быть отнесены к 
общедоступной, обособленной или защищенной части. Общедоступная часть 
«видима» для всех объектов; обособленная часть полностью закрыта для дру¬ 
гих объектов; защищенная часть «видима» только для данного класса и его 
подклассов. 

Кроме того, в C++ существует понятие связанных классов (Friend), для 
которых обособленная часть является взаимодоступной. Защита информации 
является относительной: то, что защищено на одном уровне абстракции, яв¬ 
ляется видимым на другом уровне. Только при явном неиспользовании раз¬ 
работчиком указанных возможностей и при умении воспользоваться возника¬ 
ющими трудностями можно обойти средства ограничения доступа. Ограниче¬ 
ние доступа не гарантирует от глупости, как отметил Страустрап: «Защита 
гарантирует от вмешательства, но не от обмана» [53]. Разумеется, в этой 
книге нет таких примеров, когда невозможно узнать, как реализуется пове¬ 
дение объекта, но операционная система может ограничить доступ к конк¬ 
ретным файлам, которые описывают такое поведение. Практически не всегда 
можно познакомиться с тем, как реализован тот или другой класс, понять 
его устройство, особенно при отсутствии эксплуатационной документации. 
Модульность 

Понятие модульности. По мнению Майерса, «Разделение программы на 
фрагменты позволяет частично уменьшить ее сложность... Однако гораздо 
важнее тот факт, что разделение программы улучшает проработку ее час¬ 
тей. Эти части весьма ценны для исчерпывающего понимания программы в 
целом» [54]. В некоторых языках программирования, например в Smalltalk, 
модульность не реализована и классы составляют лишь физическую основу 
декомпозиции. В других языках, включая Objest Pascal, C++, Ada, CLOS, 
модульность является элементом конструкции и позволяет осуществлять на 
ее основе проектные решения. В таких языках классы и объекты составляют 
логическую структуру системы; эти абстракции организуются в модули, об¬ 
разуя физическую структуру системы. Это свойство становится особенно по¬ 
лезным, когда система состоит из многих сотен классов. 
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По Лискову, «модульность — это разделение программы на раздельно 
компилируемые фрагменты, имеющие между собой средства сообщения». 
Можно использовать также и определение Парнаса: «Связи между модулями 
— это предположения о возможности их использования» [55]. В большинст¬ 
ве языков, поддерживающих принцип модульности как самостоятельную кон¬ 
цепцию, также реализуется разделение интерфейсной части и реализации. 
Таким образом, модульность и ограничение доступа идут неотделимо друг 
от друга. В некоторых языках программирования модульность реализуется 
особыми приемами. Например, в языке C++ модулями являются раздельно 
компилируемые файлы. Для языков C/C++ традиционным является помеще¬ 
ние интерфейсной части модулей в отдельные файлы с расширением .h (так 
называемые заголовочные файлы). 

Реализация модуля описывается в файлах с расширением .с. Взаимо¬ 
связь файлов реализуется путем включения в них макроопределения 
^include. Такой подход строится исключительно на соглашениях и не явля¬ 
ется строгим требованием самого языка. В языке Object Pascal принцип мо¬ 
дульности формализован несколько глубже. В этом языке определен особый 
синтаксис для интерфейсной части и реализация модуля, носящего имя Unit. 
В языке Ada модуль (называемый Package) также имеет две части — спе¬ 
цификацию и тело. Но в отличие от Object Pascal допускается раздельное 
определение связей модулей как для спецификаций, так и для тел. При 
этом тело модуля может быть связано с другими модулями, которые неви¬ 
димы для спецификации. 
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Правильное разделение программы на модули является почти такой же 
сложной задачей, как выбор правильного набора абстракций. Абсолютно 
прав Зелковиц, утверждая: «поскольку в начале работы над проектом реше¬ 
ния могут быть неясными, декомпозиция на модули может вызвать затруд¬ 
нения. Для хорошо известных приложений (например, создание компилято¬ 
ров) этот процесс можно стандартизовать, но для новых задач (военные сис¬ 
темы или управление космическими аппаратами) задача может быть очень 
трудной* [56]. 

Модули выполняют роль физических контейнеров, в которые помещают¬ 
ся определения классов и объектов при логическом проектировании системы. 
Это такая же ситуация, которая возникает у проектировщиков бортовых 
компьютеров. Логика электронного оборудования может быть построена на 
основе элементарных вентилей типа не, и-не, или-не, но можно и объеди¬ 
нить группы таких вентилей в стандартные интегральные схемы, например, 
серий 7400, 7402 или 7404. Отсутствие стандартизованных фрагментов дает 
программисту гораздо большую степень свободы — как если бы электро¬ 
нщик имел в своем распоряжении средства создания кремниевых кристаллов. 

Для небольших задач допустимо описание каждого класса и объекта в 
отдельном модуле. В других, наиболее тривиальных, случаях в один модуль 
лучше собрать все логически связанные классы и объекты и оставить неза¬ 
щищенными все те элементы, которые должны быть видимы для всей про¬ 
граммы. Однако такой подход применяется в исключительных случаях. 
Рассмотрим, например, задачу, которая выполняется на многопроцессорном 
оборудовании и требует для координации механизма передачи сообщений. В 
больших системах, подобных описываемым в гл. 12, вполне обычным явля¬ 
ется наличие нескольких сотен и даже тысяч видов сообщений. Было бы 
наивным определение каждого класса сообщений в отдельном модуле. При 
этом не только возникает кошмарная ситуация с документированием, но 
чрезвычайно труден для пользователя даже просто поиск нужных фрагмен¬ 
тов описания. При внесении в проект изменений потребуется модифициро¬ 
вать и перекомпилировать сотни модулей. Отсюда можно понять, что защи¬ 
та информации может обернуться и обратной стороной [57 ]. Деление про¬ 
граммы на модули безсистемным образом гораздо хуже, чем отсутствие мо¬ 
дульности вообще. 

В традиционном структурном проектировании модульность связывается в 
первую очередь с логической группировкой подпрограмм на основе принци¬ 
пов взаимной связи и общей логики. В объектно-ориентированном програм¬ 
мировании ситуация несколько иная: необходимо физически разделить клас¬ 
сы и объекты, составляющие логическую структуру проекта и явно отличаю¬ 
щиеся от подпрограмм. 

На основе имеющегося опыта можно назвать приемы и правила, кото¬ 
рые позволяют реализовать модули из классов и объектов наиболее эффек¬ 
тивным образом. Бриттон и Парнас считают, что «конечной целью декомпо¬ 
зиции программы на модули является снижение затрат на программирование 
за счет независимой разработки и тестирования. Структура модуля должна 
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быть достаточно простой для восприятия; реализация каждого модуля не 
должна зависеть от реализации других модулей; должны быть приняты меры 
для обеспечения процесса внесения изменений там, где они наиболее веро¬ 
ятны» [58]. На практике перекомпиляция тела модуля не является трудоем¬ 
кой операцией: заново компилируется только данный модуль и компонуется 
вся программа. Перекомпиляция интерфейсной части модуля, наоборот, бо¬ 
лее трудоемка. В строго типированных языках приходится перекомпилиро¬ 
вать интерфейс и тело самого измененного модуля, затем все модули, свя¬ 
занные с данным, модули, связанные с ними, и так далее по цепочке. В 
итоге для очень больших программ могут потребоваться многие часы на пе¬ 
рекомпиляцию (если только оборудование не поддерживает фрагментарную 
компиляцию), что явно нежелательно. Поэтому следует стремиться к тому, 
чтобы интерфейсная часть модулей была возможно более узкой (в пределах 
обеспечения необходимых связей). Стиль программирования требует сосредо¬ 
точивать большую часть модуля в его теле. То, что при этом в интерфейс¬ 
ную часть выносится большой объем деклараций, не так опасно, как чрез¬ 
мерный объем интерфейсного кода. 

Таким образом, программист должен находить баланс между двумя про¬ 
тивоположными тенденциями: стремлением ограничить доступ к данным и 
необходимостью обеспечения видимости тех или других абстракций в не¬ 
скольких модулях. Парнас, Клементс и Вейс предложили следующее прави¬ 
ло: «Особенности системы, подверженные изменениям следует, скрывать в 
отдельных модулях; в качестве межмодульных можно использовать только те 
элементы, вероятность изменения которых мала. Все структуры данных дол¬ 
жны быть обособлены в модуле; доступ к ним будет возможен для всех 
процедур этого модуля и закрыт для всех других. Доступ к данным из дру¬ 
гого модуля должен осуществляться только через процедуры данного моду¬ 
ля* [59]. Другими словами, следует стремиться построить модули так, что¬ 
бы объединить логически связанные абстракции и минимизировать взаимные 
связи между модулями. Исходя из этого, приведем определение модульности: 

Модульность — это свойство системы, связанное с возможностью 
декомпозиции ее на ряд тесно связанных модулей. 

Таким образом, принципы абстрагирования, ограничения доступа и мо¬ 
дульности являются взаимодополняющими. Объект определяет явные границы 
определенной абстракции, а ограничение доступа и модульность создают 
барьеры между абстракциями. 

В процессе разделения системы на модули могут быть полезными два 
правила. Первое состоит в следующем: поскольку модули служат в качестве 
элементарных и неделимых блоков программы, которые могут использоваться 
в системе многократно, распределение классов и объектов должно создавать 
для этого максимальные удобства. Второе правило вытекает из того факта, 
что многие компиляторы создают отдельный сегмент кода для каждого моду¬ 
ля. Поэтому размер модуля должен быть соответственно ограничен. Объявле¬ 
ние функций в модуле может оказать большое влияние на возможность их 
вызова из другого модуля, так как это связано с разделением памяти на 
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страницы. Большое количество вызовов между сегментами загружает кэш-па¬ 
мять и снижает характеристики всей системы. 

Следует сказать о нескольких других моментах. При коллективной раз¬ 
работке программ распределение работы осуществляется, как правило, по 
модульному принципу и правильное разделение проекта минимизирует связи 
между участниками проекта. При этом более опытные программисты обычно 
отвечают за интерфейс модулей, а менее опытные — за остальную часть 
модулей. На более крупном уровне такие же соотношения справедливы для 
предприятий-соисполнителей. В последнем случае изменения в интерфейсе 
вызывают большое «напряжение» независимо от объема этих изменений, что 
оказывает сильное влияние на проектирование интерфейса. Что касается до¬ 
кументирования проекта, то оно строится, как правило, также по модульно¬ 
му принципу. К сожалению, иногда требования по документированию 
считаются главными при декомпозиции проекта (в большинстве случаев 
имея негативные последствия). Там, где один модуль требует большого объ¬ 
ема документирования, делается десять модулей. Могут сказываться требова¬ 
ния секретности: часть кода может быть несекретной, а другая — секрет¬ 
ной; последняя в виде отдельного модуля (модулей). 

Перечисленные факторы имеют множество взаимных связей, но главным 
является следущее: вычленение классов и объектов в проекте, а также орга¬ 
низация модульной структуры — существенно независимые решения. Про¬ 
цесс вычленения классов и объектов составляет часть процесса логического 
проектирования системы, а деление на модули — этап физического проекти¬ 
рования. Иногда невозможно завершить логическое проектирование системы, 
не завершив физическое проектирование, и наоборот. Два этих процесса 
выполняются итеративно. 

Примеры модульности. Посмотрим, как реализуется модульность в теп¬ 
личном хозяйстве. Допустим, что для реализации интерфейса пользователя 
решено использовать стандартную рабочую станцию, а не какое-либо специ¬ 
альное оборудование. С помощью такой рабочей станции оператор может 
формировать новый план выращивания, модифицировать имеющиеся планы 
и наблюдать за исполнением плана. Для иллюстрации этой части системы 
можно воспользоваться языком Object Pascal как наиболее общедоступным. 
Ключевой абстракцией здесь является план выращивания. Необходимо, сле¬ 
довательно, создать модуль, связывающий все классы, относящиеся к планам 
выращивания. Основа такого модуля на Object Pascal будет выглядеть следу¬ 
ющим образом: 
unit UGrowingPlans; interface 

implementation 

{$1 UGrowingPlans.incl.p} 

end. 

Многоточием отмечена область деклараций, которая доступна для внеш¬ 
них модулей. Реализация классов, объектов и отдельных процедур этого мо¬ 
дуля содержится в отдельном файле UGrowingPlans.incl.p. 
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Введем также модуль UGardeningDialogs, где будет собрано все, что от¬ 
носится к организации диалога с оператором. Поскольку этот модуль логи¬ 
чески связан с классами модуля UGrowing Plans, его общая структура будет 
следующей: 

unit UGardeningDialogs; interface 


Memtype, QuickDraw, OSIntf, Toollntf, Packlntf, CursorCtr, 
UMAUtil, UViewCoords, UFailure, UMemory, UMenuSetup, 
UObject, UList, UAssociation, UMacApp, 

UGrowingPlans; 


implementation 

{$1 UGardeningDialogs.incl .p} 

end. 


Реализация данного модуля требует доступа к различным интерфейсам 
низкого уровня, что видно из описания интерфейсной части. 

В проект может входить множество других модулей, таких, как 
UGardeningCommands, UGardeningWiews, UGardeningDocuments, 

UGardeningApplication, каждый из которых использует интерфейс модулей 
более низкого уровня. В конечном счете мы должны определить основное 
тело всей программы, вызываемой из операционной системы. В объектно- 
ориентированном проектировании это является самым простым моментом, 
тогда как в структурном программировании тело программы составляет кос¬ 
тяк и краеугольный камень, на который опирается все остальное. Объектно- 
ориентированный подход выглядит более естественно, как отметил Мейер: 
«Реальные программные системы более удобно описывать как совокупность 
сервисных механизмов. Как правило, можно описать систему с помощью от¬ 
дельных функций, но слишком многое зависит от умения ... Для практиче¬ 
ской реализации систем нет предела» [60]. 

Иерархия 

Понятие иерархии. Абстракция — вещь полезная, но всегда, кроме са¬ 
мых простых ситуаций, число абстракций в системе намного превышает воз¬ 
можности их одновременного контроля. Ограничение доступа позволяет в ка¬ 
кой-то степени устранить это препятствие, убрав из поля зрения внутреннее 
содержание абстракций. Модульность также упрощает задачу, объединяя ло¬ 
гически связанные абстракции в группы. Но этого оказывается недостаточно. 

Значительное упрощение в понимании сложных задач достигается за 
счет образования иерархической структуры из абстракций. Определим иерар¬ 
хию следующим образом: 

Иерархия — это ранжированная или упорядоченная система абстрак¬ 
ций. 

Основными видами иерархических структур применительно к сложным 
системам являются структура классов (иерархия по номенклатуре) и струк¬ 
тура объектов (иерархия по составу). 

Примеры иерархии: простое наследование. Важным элементом объект¬ 
но-ориентированных систем и основным видом иерархии по номенклатуре 
является упоминавшаяся выше концепция наследования. Наследование озна¬ 
чает такое соотношение между классами, когда один класс использует 
структурную или функциональную часть одного или нескольких других 
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классов (соответственно простое и множественное наследование). Иными сло¬ 
вами, наследование — такая иерархия абстракций, в которой подклассы на¬ 
следуют строение от одного или нескольких суперклассов. 

Рассмотрим, например, различные виды растений, выращиваемых в теп¬ 
лицах. Выше уже была рассмотрена обобщенная абстракция плана выращи¬ 
вания растений. Однако для оптимизации урожая план должен быть специа¬ 
лизирован в зависимости от культур (например, для овощей, фруктов и 
цветов). Это означает, что стандартный план выращивания фруктов являет¬ 
ся разновидностью плана выращивания дополненного особенностями, напри¬ 
мер сроками созревания. Подобные соотношения могут быть определены на 
языке C++ следующим образом: 

class StandardFruitGrowingPlan: public GrowingPlan { 
public: 

StandardFruitGrowingPlan (); 

StandardFruitGrowingPlan (const StandardFruitGrowingPlandr); 

virtual -StandardFruitGrowingPlan (); 

virtual int daysUntilHarvest (day currentDay) const; 

day timeToHarvest; 

}; 


Из приведенного определения видно, что класс StandartFruitGrowingPlan 
точно повторяет свой суперкласс Growing Plan за несколькими исключения¬ 
ми. В подкласс введен новый элемент структуры (timeToHarvest), изменены 
конструктор и деструктор, добавлена виртуальная функция 
(daysUntilHarvest). Используя этот новый класс уже в качестве суперкласса, 
можно определить еще более специализированные подклассы, например для 
плана выращивания яблок. 

Для установленной наследственной иерархии общая часть структуры и 
поведения сосредоточена в наиболее общем суперклассе. По этой причине 
говорят о наследовании, как об иерархии обобщения-специализации. Супер¬ 
классы при этом отражают наиболее общие, а подклассы — более специали¬ 
зированные абстракции, которые могут быть одновременно дополнены, моди¬ 
фицированы и даже защищены. Принцип наследования позволяет упростить 
выражения абстракций, делает проект менее громоздким и более вырази¬ 
тельным. Кокс пишет: «В отсутствие наследования каждый класс становится 
самостоятельным блоком и должен разрабатываться «с нуля». Классы лиша¬ 
ются взаимоотношений, и их методическая часть реализуется каждым про¬ 
граммистом по-своему. Стройность системы может быть достигнута только 
на основе дисциплины программистов. Принцип наследования позволяет со¬ 
здавать новые программы и обучать новичков на основе уже готовых про¬ 
дуктов» [61]. 

Принципы абстрагирования, ограничения доступа и иерархии 
конкурируют между собой. Данфорт и Томлисон утверждают: «Абстрагирова¬ 
ние данных состоит в установлении жестких границ, защищающих состояние 
и функции объекта; принцип наследования требует открыть доступ и к со¬ 
стоянию, и к функциям объекта для производных объектов» [62]. Для лю¬ 
бого класса обычно существуют два вида объектов-пользователей: объекты, 
которые используют операции данного класса для доступа к его элементам, 
и объекты-подклассы, полученные наследованием данного класса. Лисков 
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считает, что существуют три способа нарушения механизма ограничения до¬ 
ступа через механизм наследования: «подкласс может получить доступ к 
данным своего суперкласса, осуществить вызов обособленной (защищенной) 
функции суперкласса и обратиться напрямую к суперклассу своего супер¬ 
класса» [63]. Различные языки программирования по-разному реализуют ме¬ 
ханизмы наследования и ограничения доступа, наиболее гибким в этом от¬ 
ношении является C++. В нем интерфейсная часть класса может быть разде¬ 
лена на три части: обособленную — видимую только для самого класса, за¬ 
щищенную — видимую также и для подклассов; общедоступную — види¬ 
мую для всех. 

Множественное наследование. В предыдущем примере рассматривалось 
простое наследование, когда подкласс создается только из одного суперклас¬ 
са. В ряде случаев полезно реализовать наследование от нескольких супер¬ 
классов. Предположим, что нужно определить класс, представляющий разно¬ 
видности растений. Используем для этого язык CLOS и получим следующее: 


(date-planted 

(germination-time 

(actual-germinatioi 


:reader plant-name) 
:initarg :date-planted 
:reader date-planted) 
:initarg :germination-time 
:readcr germination-time) 
:initform nil 


^documentation «The base class of all plants.»)) 


Структура такого объекта состоит из четырех слотов (паше, date- 
planted, germination-time, actual-germination). Для каждого слота определены 
методы инициализации Ginitarg и :initform), для первых трех слотов — ме¬ 
тоды чтения данных Greader), а для четвертого слота — методы чтения и 
записи Gaccessor). 

Мы уже определили, что в тепличном хозяйстве выращивание цветов, 
овощей и фруктов имеет свою специфику. Например, для цветов важно 
знать момент зацветания, а для фруктов момент сбора урожая. Чтобы реа¬ 
лизовать указанные требования, необходимо из данного класса Plant образо¬ 
вать два новых класса — Flowering-plant и Fruit/vegetable-plant. А что если 
потребуется план, моделирующий сразу и выращивание цветов, и созревание 
фруктов? Цветоводы иногда используют цветы яблонь, вишни и слив. Тогда 
потребуется создать третий класс, включающий оба предыдущих подкласса. 
Но лучший путь решения указанной проблемы без подобной избыточности 
— множественное наследование. Для этого создаются отдельно классы для 
овощей, фруктов и цветов: 


(defclass flowering-plant-mixin () 

((time-to-flower : initang :time-to-flower 

: reader time-to-flower) 

(time-to-seed : initang :lime-to-seed 

:reader time-to-seed)) 

Cdocumentation «А mixin class for flowering plants.»)) 

(defclass fruit/vegetable-plant-mixin 0 

((time-to-harvest : initang :time-to-harvest 

:reader time-to-harvest)) 

Cdocumentation «А mixin class for fruits and vegetables.»)) 
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Эти классы самостоятельны и не имеют суперкласса. Они предназначе¬ 
ны для последующего смешения между собой с целью создания подклассов. 
Например, подкласс для выращивания цветов будет следующим: 

(defdaas flowering-plant (plant flowering-plant-mlxin) 

О 

(documentation «А flowering plant class.»)) 

а для фруктов и овощей другим: 

(defdass fruit/vegetable-plant (plant fruit/vegetable-plant-mixin) 

0 

(documentation «А fruit or vegetable plant.»)) 

Во всех случаях подкласс образован наследованием от двух суперклас¬ 
сов. Структура полученных подклассов содержит все необходимые элементы. 

Теперь определим класс для фруктов и цветов одновременно: 

(defclass flowering/fruit/vegetable-plant (plant 

flowering-plant-mixin 

fruit/vegetable-plant-mixin) 

0 

(documentation «А flowering fruit or vegetable plant .»)) 

Агрегатирование. Если иерархия по номенклатуре определяет отношение 
обобщения-спецификации, то иерархия по составу определяет отношения аг¬ 
регатирования. Например, приведенный выше объект состоит из шести мень¬ 
ших объектов (четыре слота из класса plant и два из класса flowering-plant- 
mixin). Для таких иерархических структур часто употребляется термин 
«уровни абстракций», впервые введенный в работе [64]. Для иерархии по 
номенклатуре более высокому уровню соответствуют более общие абстрак¬ 
ции, а более низкому — специализированные. В упомянутом примере класс 
plant является абстракцией более высокого уровня, чем flowering-plant. Для 
иерархии по составу более высокий уровень представляют те абстракции, 
которые используют в своем составе другие классы. Следовательно, класс 
StandardFruitGrowingPlan более высокого уровня, чем тип day, входящий в 
его состав. 

Типизация 

Понятие типизации. Концепция типизации строится на понятии типов 
абстрактных данных. По определению Дейтча: «Тип — это точное определе¬ 
ние свойств строения или поведения, которое присуще некоторой совокупно¬ 
сти объектов» [65]. Далее для удобства термины «тип» и «класс» будут ис¬ 
пользоваться в качестве эквивалентов 1 *. Несмотря на схожесть понятий 
«класс» и «тип», в качестве отдельного элемента объектного подхода выделя¬ 
ется типизация, поскольку эта концепция подчеркивает различные особенно¬ 
сти абстракций. Определим типизацию следующим образом: 


11 Тип и класс — не одно и то же; в некоторых языках эти два понятия различаются. 
Например, ранние версии языка Trellis/Owl позволяют объекту иметь как класс, так и тип. 
Даже в языке Smalltalk объекты классов Smalllnteger, LargeNegativelnteger и LargePositivelnteger 
принадлежат одному и тому же типу Integer но разным классам [66]. Для большинства людей 

тем не менее разделение понятий типа и класса крайне неудобно и приносит мало пользы. 

Достаточно сказать, что класс реализует тип. 
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Типизация — это ограничение, накладываемое на класс объектов и 
препятствующее взаимозамене различных классов (или сильно сужающее 
возможность такой взаимозамены). 

Типизация позволяет выполнять описание абстракций таким образом, 
что реализуется поддержка проектных решений на уровне языка программи¬ 
рования. О важности такого вида поддержки для программирования на уров¬ 
не больших проектов заметил Вегнер [67]. В то же время объектные и объ¬ 
ектно-ориентированные языки программирования могут быть строго ти¬ 
пизированы, нестрого и совсем не типизированы, что позволяет говорить о 
типизации как о второстепенном элементе. 

Примеры строгой и нестрогой типизации. Возвращаясь к примеру реа¬ 
лизации интерфейса пользователя в тепличном хозяйстве, предположим, что 
имеется следующее описание классов (неполное) на языке Object Pascal: 

TShape - object (TObject) 
fPosition: Point; 

procedure TShape.Draw (Area: Rect); 
function TShape.IsVisible: Boolean: 


TText - object (TShape) 
fVaiue:Str255; 

procedure TText.Draw (Area: rect); override; 

end; 

TGreenhouse - object (TShape) 

fHydroponics_Tanks: array[1..10] of ThydroponicsTank; 

procedure TGreenhouse.Initialize; 

procedure TGreenhouse.Draw (Area: rect); override; 


В языке Object Pascal все объявленные в интерфейсной части класса 
поля и операции являются общедоступными. Следовательно, реализация опе¬ 
раций такого класса является «видимой». Это дает основания говорить о не¬ 
полной реализации в Object Pascal концепции ограничения доступа. 

В качестве суперкласса для ряда объектов, связанных с обслуживанием 
экрана рабочей станции, введен класс TShape путем наследования базового 
класса TObject. Более специализированными подклассами, объекты которых 
являются изображениями на экране, служат TText и TGreenhouse. В классе 
TShape введен общий метод Draw, так как все объекты связаны с изображе¬ 
ниями; в подклассах TText и TGreenhouse этот метод доопределен для вы¬ 
вода текстов и изображения теплицы соответственно. 






Строгая типизация ограничивает перечень абстракций, которые 
могут быть использованы в конкретной процедуре. 

Object Pascal является строго типизированным языком и требует явного 
определения типа каждой переменной, параметра и поля в описании класса. 
Предположим следующий набор определений: 

AnObject : TObjecl; 

AShape : TShape; 

ATextString : TText; 

AGreenhouse : TGrcenhouse; 

Теперь можно указать операторы для образования новых объектов: 

new (AnObject); 
new (AShape); 
new (ATextString); 
new (AGreenHouse); 

Переменные, подобные ATextString, не являются объектами. 
ATextString — это только имя для обозначения объекта класса TText: когда 
говорят «Объект ATextString», в действительности имеют в виду экземпляр 
объекта TText, отмеченный переменной ATextString. Эта особенность будет 
подробно рассмотрена в следующей главе. 

Строгая типизация в Object Pascal требует проверки во время компиля¬ 
ции на соответствие типов в операторах вызова процедур. Ниже приведен 
пример правильного написания операторов: 

{Draw is defined for the 
ea); {Draw is defined for the 


AShape.Draw (SomeArea); 
ATextString.Draw (SomeArt 


class TShape} 
class TText} 
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Следующие операторы содержат ошибки и не смогут пройти через про¬ 
цесс компиляции: 

AnObject.Draw (SomeArea); {illegal} 

ATexlString.Initialize; {illegal} 

Ошибки в этих операторах заключаются в том, что методы Draw и 
Initialize не определены для соответствующих переменных ни в их классах, 
ни в суперклассах. А следующий оператор написан верно: 

if AGreenhouse.IsVisible then 


Хотя метод IsVisible не определен для класса TGreenhouse, но он опре¬ 
делен в его суперклассе TShape. Рассмотрим тот же пример на нети- 
пизированном языке Smalltalk. 

Переменные в следующем определении являются нетипизированными: 

I anObject aShape ATextString aGreenhouse I 
Следующий оператор 
anObject draw: SomeArea. 

пройдет через компиляцию, но точный его смысл останется неясным до за¬ 
пуска программы на исполнение. Если переменная anObject окажется связан¬ 
ной с классом Shape (имеющий в своем описании, метод draw), то програм¬ 
ма будет выполнена без ошибок. И наоборот, еслц anObject окажется свя¬ 
занной с экземпляром класса Bad (предопределенного в Smalltalk и не име¬ 
ющего метода draw в своем описании), то возникнет ошибка при выполне¬ 
нии программы. 

Строго типизированными являются такие языки, в которых все выраже¬ 
ния проходят проверку на соответствие типов. В описанном ниже примере, 
иллюстрируется смысл соответствия типов на основе сделанных ранее опре¬ 
делений на Object Pascal. Следующие два оператора верны: 

AnObject AnObject; 

AShape ATextString; 

В первом операторе класс переменной левой части соответствует классу 
выражения правой части. Во втором операторе класс переменной левой час¬ 
ти (TShape) является суперклассом переменной правой части (TText). Рас¬ 
смотрим другие два оператора: 

AGreenhouse :-AShape; {illegal} 

ATextString :-AGreenhouse; {illegal} 

Оба оператора ошибочны, так как класс переменной в левой части опе¬ 
раторов является подклассом переменной в правой части. Иногда возникает 
необходимость преобразовать переменную одного типа в переменную другого 
типа. Например, для предопределенного в библиотеке Object Pascal класса 
TList имеется операция Each, позволяющая получить доступ к любому эле¬ 
менту списка: 

procedure TList.Each (procedure DoToItem (Item: TObject)); 

5 Гради Буч 
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Если известно заранее, что список всегда состоит из объектов класса 
TGreenhouse, то можно реализовать явную связь значений двух типов, как 
в следующем ниже операторе присвоения: 

procedure DoToItem (Item : TObject); 

AGreenhouse TGreenhouse (Item); 


Этот оператор удовлетворяет требованиям соответствия типов, но не га¬ 
рантирует абсолютного соответствия. Если, например, во время исполнения 
программы в списке окажется объект класса TText, то возникнет ошибка. 

Теслер [68] отметил следующие важные преимущества строго типизиро¬ 
ванных языков: 

* «Отсутствие контроля типов может приводить к загадочным сбоям в про¬ 
граммах во время их выполнения. 

* В большинстве случаев процесс повторного редактирования-компиляции-от- 
ладки достаточно утомителен и раннее обнаружение ошибок является обя¬ 
зательным условием. 

* Декларирование типов упрощает документирование программ. 

* Многие компиляторы позволяют генерировать более эффективный код при 
явном определении типов». 

Языки, в которых типизация отсутствует, обладают большей гибкостью, 
но даже для таких языков, по мнению Борнинга и -Ингалса: «в большинстве 
случаев программисты фактически знают, какие объекты выступают в каче¬ 
стве аргументов и какие будут возвращаться» [69]. На практике, для боль¬ 
ших систем, надежность языков со строгой типизацией компенсирует некото¬ 
рую потерю в гибкости по сравнению с нетипизированными языками. 

Статическая и динамическая связь. Концепции строгой и статической 
типизации по существу различны. Строгая типизация имеет отношение к 
контролю соответствия типов, а статическая (иначе называется статической 
или ранней связью) — имеет отношение ко времени, когда имена связыва¬ 
ются с типами. Статическая связь означает неизменность типов всех пере¬ 
менных и выражений во время компиляции; динамическая связь (называе¬ 
мая также поздней связью) означает ситуацию, когда тип всех переменных 
и выражений определяется только во время исполнения программы. Концеп¬ 
ции типизации и связей являются независимыми, поэтому язык программи¬ 
рования может быть строго типизирован со статической связью (Ada) и с 
динамической связью (Smalltalk). Язык CLOS занимает промежуточное поло¬ 
жение между C++ и Smalltalk, так что при реализации определения, сделан¬ 
ные программистом, могут быть либо приняты, либо не приняты. Поясним 
сказанное на примере, в котором используется Object Pascal. Выше уже ис¬ 
пользовался класс TList из библиотеки Object Pascal, представляющий собой 
связанный список. Определим этот класс следующим образом: 

TUst - object (TObject) 

procedure TList.InsertFirst (Item: TObject); 

procedure TList.Each (procedure DoToItem (Item: TObject)); 
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Здесь использованы два метода: один для включения в список нового 
элемента (модификатор), другой для доступа к отдельным элементам списка 
(итератор). Так как Object Pascal поддерживает динамические связи, список 
может быть либо однородным (все элементы одного определенного класса), 
либо разнородным (из элементов разных классов) при условии, что каждый 
элемент списка является реализацией класса TObject или любого его под¬ 
класса. 

Предположим, что имеется объект класса TList с именем AList, пред¬ 
ставляющий собой разнородный список объектов класса TShape и производ¬ 
ных от него подклассов. Тоща можно записать следующие операторы: 

Alist.InsertFirst (AShape); 

Alist.InsertFirst (ATextString); 

Alist.InsertFirst (AGreenhouse); 

Эти операторы отвечают принципу соответствия типов, так как действи¬ 
тельные параметры в каждом из них являются объектами того же класса 
(или -подклассом) соответствующего формального параметра (TObject). 

Предположим, что нужно написать процедуру вывода на экран произ¬ 
вольного объекта из такого списка. Например, 

procedure Draw ltem (Item: TObject); 
begin 

TShape (Item) .Draw (SomeArea); 

end; 

AList.Each <Draw_Item); 

Обращение к операции Eeach активизирует итератор списка, который в 
свою очередь обращается к процедуре Draw_Item. Отметим, что в процедуре 
Draw_Item переменная Item связана с классом TShape и его подклассами, 
что позволяет обратиться к процедуре Draw. Однако во время компиляции 
не известно, какой подкласс связан с объектом, обозначенным формальным 
параметром Item: это могут быть, в частности, классы TText или 
TGreenhouse. Это пример динамической связи. 

Гарантию того, что формальный параметр Item будет связан с классом 
TShape, создает контроль занесения объектов в список. Поскольку для клас¬ 
са TShape определен метод Draw, вызов этой процедуры отвечает условиям 
согласования типов. Таким образом, вызов итератора Each приводит к про¬ 
хождению по списку и к вызову процедуры Draw для каждого элемента 
списка. Поскольку объекты списка могут быть разными (относиться к раз¬ 
ным классам), то и вызов метода Draw должен выполняться по-разному. В 
конечном счете только при выполнении программы обнаружится, какая из 
процедур Draw будет действительно выполнена. Это свойство называется по¬ 
лиморфизмом: определенное имя (объявленная переменная) может означать 
объект любого класса, относящегося к определенному суперклассу. Любой из 
объектов, связанных с таким именем, должен выполнять некоторое множест- 
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во общих операций [70]. Противоположностью полиморфизма является моно¬ 
морфизм, свойственный всем языкам со строгой типизацией и статическими 
связями, например языку Ada. 

Полиморфизм возникает на стыке принципов наследования и динамиче¬ 
ских связей. Это свойство является самым существенным в объектно-ориен¬ 
тированном программировании наряду со свойством реализации абстракций. 
Именно это свойство отличает OOP от более традиционных методов про¬ 
граммирования с использованием типов абстрактных данных. Кроме того, 
как мы увидим ниже, полиморфизм является важной концепцией в объект¬ 
но-ориентированном проектировании. 

Параллелизм 

Понятие параллелизма. Для определенной категории задач автоматиче¬ 
ские системы реализуют обработку многих событий, происходящих одновре¬ 
менно. В других случаях время, затрачиваемое на вычисления, превышает 
ресурсы одного процессора. В обеих ситуациях естественно предложить ис¬ 
пользование нескольких компьютеров для решения общей задачи или для 
реализации многозадачного режима обработки. Одиночный процесс (извест¬ 
ный также как канал управления) — это путь, начало которого находится 
в том месте системы, где возникает некоторое независимое динамическое 
воздействие. Любая программа включает по меньшей мере один канал уп¬ 
равления, но в параллельной системе таких каналов может быть несколько: 
одни могут быть временными, а другие могут сохраняться в течении всего 
времени выполнения программы. Реальная параллельность достигается только 
на многопроцессорных системах, а системы с одним процессором имитируют 
параллельность за счет алгоритмов разделения времени. 

Лим и Джонсон утверждают: «Реализация параллельности в объектно- 
ориентированных языках такая же, как в любых других языках, — парал¬ 
лелизм не связан с OOP на самом нижнем уровне абстракции» [71 ]. Что 
касается создания больших программных систем, охватывающих множество 
каналов управления, то здесь ситуация гораздо сложнее: можно упустить из 
внимания тупики, блокировки, исчерпание процесса, взаимные противоречия 
и временные ограничения. К счастью, как отмечают те же авторы: «на вер¬ 
хних уровнях абстракции OOP позволяет упростить решение вопросов па¬ 
раллелизма для большинства программистов, ограничивая параллелизм внут¬ 
ри множественных абстракций» [72]. Блэк и другие авторы сделали следую¬ 
щий вывод: «объектный подход удовлетворяет требованиям распределенных 
систем, поскольку неявно определяет блоки распределения и перемещения и 
взаимодействующие объекты» [73]. 

В то время как объектно-ориентированное программирование строится 
на абстракции данных, ограничении доступа и наследовании, параллелизм 
связан с абстрагированием процессов и синхронизацией [74]. Объект являет¬ 
ся основой, которая объединяет обе концепции: каждый объект (как абст¬ 
ракция реальности) может представлять собой отдельный канал управления 
(абстракцию процесса). Такой объект называется активным. Для систем, по¬ 
строенных на основе OOD, реальность может быть представлена как сово¬ 
купность взаимодействующих объектов, часть которых является активной и 
выступает в роли узлов независимых действий. На этой основе дадим следу¬ 
ющее определение параллелизма: 




Параллелизм характеризует возможность одновременного функциониро¬ 
вания объектов. 


Параллелизм — свойство объектов находиться в активном, либо пас¬ 
сивном состоянии. 

Примеры параллелизма. Рассмотрим абстракции, определенные на языке 
Ada, для последовательности классов, представляющих датчики температуры. 
Мы уже говорили о классе активных датчиков, которые периодически изме¬ 
ряют температуру и посылают сообщение другому объекту при изменении 
температуры на определенную величину. Чтобы показать с помощью языка 
Ada механизм описания параллельных процессов, следует дополнить опреде¬ 
ление класса Air_Temperature_Sensor следующим образом (не рассматривая 
здесь операцию калибровки): 

task type Air_Temperature_Sensor is 

entry Initialize (ItsJLocation 

LowerAlarmLlmit 
Upper_Alann_Limit 

end Air Temperature Sensor; 

Для каждого элемента в такого рода задачах создается новый процесс. 
С точки зрения объектной ориентации над подобными объектами можно вы¬ 
полнять только одно действие. В частности, такой объект можно инициали¬ 
зировать, сообщив ему место расположения, верхнюю и нижнюю темпера¬ 
турные границы (вне которых действуют другие объекты через формальный 
параметр Temperature_Alarm). Допустим, что обмен информацией датчики 
осуществляют через определенную область памяти. 

На языке Ada указанные выше решения будут выражены в теле пакета 
Аіг_Т emperature_Sensors следующим образом: 


in Location; 
in Temperature; 
in Temperature); 
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type Word is range — (2” 15 r'l) .. )2*»15 -1); 
for Word’Size use 16; 

Sensor_Memory_Map: array (Location) of Word; 
for Sensor_Memory_Map use at 16#377FF0#; 


Tirae_Interval: constant Duration:-2.0; 

Введенные декларации являются защищенными как скрытая часть абст¬ 
ракции и потому, что отведенная для обмена данными область памяти на¬ 
чинается с 16-ричного адреса 377FF0, а под каждый датчик отведено 16- 
разрядное число. Константа Time_Interval определяет периодичность чтения 
данных из физического датчика (в данном случае один раз в 2 с). Суть 
этой задачи состоит в чтении каждые 2 с данных из определенной области 
памяти и сообщении другим объектам о наличии изменений или об аварий¬ 
ной ситуации. Без учета вопросов калибровки и конечных условий тело за¬ 
дачи будет выглядеть следующим образом: 


task body Air_Temperature_Sensor 
CurrentLocation 
Sensor_Value 
Current_Temperature 
Previous_Temperature 
LowerjJmit 
Upper_Limit 
Next_Time 


: Location; 

: Word; 

: Temperature; 

: Temperature;-Temperature’Last; 
: Temperature; 

: Temperature; 

: Calendar.Timet-Calendar.Clock; 


accept Initialize' (Its_Location 

Lower_Alarm_Limit 

UpperAlarmLimit 

Current_Location 

Lower_Limit 

Upper_Limit 


in Location; 
in Temperature; 
in Temperature) do 
Its_Location; 
-Lower_Alarm_Limit; 
-Lower_Alarm_Limit; 


end Initialize; 
loop 


delay (Next_Time — Calendar.Clock); 

Sensor_Value:-Sensor_Memory_Map (Current_Location); 

Current_Temperature;- Temperature (Float (Sensor_Value) ’Temperature’Delta); 
if (Current_Temperature /-Previous_Temperature) then 
if (Current_Tpmperature<Lower_Umlt) or 
(Current_Temperature>Upper_Limit) then 
Temperature_Alarm (Current Location, Current_Temperature); 
else 


Previous_Temperature:-Current_Temperature; 

Temperature_Has_Changed (CurTent_Location, Current_Temperature); 

end if; 
end if; 

Next_Time:-Next_Time + Time_Interval; 


Для большей ясности этот пример содержит некоторое избыточное чис¬ 
ло локальных переменных, чем необходимо в действительности. После ини¬ 
циализации активного объекта его процесс повторяется периодически через 
каждые несколько секунд в течение всего времени чтения данных из физи- 






Объект 


ческого датчика. Если новое прочитанное значение отличается от предыду¬ 
щего, алгоритм не прерывается. Но если новое значение вышло за установ¬ 
ленные пределы, вызывается процедура Temperature_Alarm. В остальных слу¬ 
чаях для сообщения об изменении температуры другими объектами исполь¬ 
зуется процедура Temperature_Has_Changed. 

Как только в систему введен параллелизм, сразу возникает вопрос о 
том, как синхронизировать отношения между активными объектами, а также 
с остальными объектами, действующими последовательно. Например, следует 
предусмотреть разрешение ситуаций, когда два объекта одновременно посы¬ 
лают сообщение третьему, чтобы предотвратить сметание данных. При на¬ 
личии параллелизма недостаточно просто описать методическую часть, необ¬ 
ходимо предусмотреть в ней способы защиты для случая многоканального 
управления. 

Существуют экспериментальные параллельные объектно-ориентированные 
языки программирования (Actor, Orient 84/К, ABCL/1), имеющие механиз¬ 
мы активизации и синхронизации. Более подробные сведения о них и о ря¬ 
де других приведены в приложении. Из числа языков, использованных в 
данной книге, многозадачный режим реализуют прямо только Smalltalk и 
Ada (Smalltalk содержит, класс Process для этой цели, a Ada реализует тип 
«task»). 

В C++ параллельные объекты могут быть реализованы в системе Unix 
вызовом fork. Object Pascal и CLOS обычно используются только для после¬ 
довательных задач и не имеют механизмов распараллеливания. 



Устойчивость позволяет объектам сохранять свое состояние и при¬ 
надлежность к определенному классу. 
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Устойчивость 

Любой объект в программе занимает определенное место и существует 
в течение определенного времени. Аткинсон и другие выдвинули гипотезу о 
континууме способов существования объектов, начиная с преходящих объек¬ 
тов, которые существуют лишь во время определенных вычислений, и кон¬ 
чая объектами в базах данных, которые существуют даже вне пределов про¬ 
граммы. В этот спектр, определяющий устойчивость объектов, можно вклю¬ 
чить следующие виды: 

* «Промежуточные результаты вычисления выражений. 

* Локальные переменные в вызове процедур. 

* Собственные переменные (например, в ALGOL-60), глобальные переменные 
и главные элементы. 

* Данные, сохраняющиеся между вызовами основной программы. 

* Данные, остающиеся без изменений в разных версиях программы. 

* Данные, которые переживают всю программу» [75]. 

Традиционные языки программирования, как правило, реализуют только 
три первых уровня устойчивости, а последние три обычно связываются с 
технологией баз данных. Это приводит к неожиданным решениям: програм¬ 
мисты разрабатывают специальные схемы для сохранения объектов в период 
между запуском программы, а конструкторы баз данных адаптируют свою 
технологию под временно живущие объекты [76]. 

Унификация принципов параллелизма для объектов позволила бы в 
этом случае подняться до уровня требований объектно-ориентированного про¬ 
граммирования. Аналогичным образом реализация принципа устойчивости в 
объектном подходе поднимает его на уровень объектно-ориентированных баз 
данных (OODB). На практике подобные базы данных строятся на хорошо 
проверенных принципах, таких, как последовательные, индексированные, 
иерархические, сетевые или реляционные модели. Для программиста они ре¬ 
ализуют абстракцию объектно-ориентированного интерфейса, благодаря чему 
упрощается доступ к базе данных и другие операции с объектами, время 
существования которых превышает время функционирования отдельной про¬ 
граммы, унифицируются. Эта унификация значительно упрощает разработку 
отдельных видов программ, позволяя, в частности, применить единый подход 
к разным сегментам программы, одни из которых связаны с базами данных, 
а другие не имеют такой связи. 

Число OODB очень ограничено, это TAXIS, SDM, DAPLEX и 
GEM [77 ]. Ни один из пяти языков программирования, упоминаемых в 
данной книге, не поддерживает прямо концепцию устойчивости, поэтому не 
приводятся и соответствующие примеры. Однако в гл. 9 и 10 будет показа¬ 
но, что имеется возможность имитации устойчивости на известных языках 
программирования. 

Устойчивость — понятие, связанное не только с временем существова¬ 
ния данных. В OODB сохраняется не только состояние объекта, но и способ 
интерпретации класса любой другой программы должен быть определен од¬ 
нозначно. Из этого можно понять всю сложность управления базой данных 
в процессе ее наращивания, в частности при изменении классов объектов. 
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Далее рассматривается только устойчивость во времени. В большинстве сис¬ 
тем в течение всего времени существования объекты занимают определенное 
место в физической памяти. Для многопроцессорных систем можно рассмат¬ 
ривать и вопрос устойчивости в пространстве. В таких системах необходимо 
рассмотреть перемещение объекта между процессорами и даже изменение 
при этом способа представления объектов. Эта разновидность устойчивости 
рассмотрена в гл. 12. В заключение дадим следующее определение устойчи¬ 
вости: 

Устойчивость — свойство объекта существовать во времени (вне за¬ 
висимости от процесса, породившего данный объект) и (или) в простран¬ 
стве (перемещение объекта из адресного пространства, в котором он был 
создан). 

2.3. ПРИМЕНЕНИЯ ОБЪЕКТНОГО ПОДХОДА 
Преимущества объектного подхода 

Как уже говорилось выше, объектный подход принципиально отличается 
от тех подходов, которые связаны с более традиционными методами струк¬ 
турного анализа, проектирования и программирования. Это не означает, что 
объектный подход требует отказа от всех ранее найденных и испытанных 
методов и приемов, напротив, новые элементы всегда основываются на пред¬ 
шествующем опыте. Объектный подход создает множество существенных 
удобств, которые при других условиях не могут быть обеспечены. Наиболее 
важным является то, что объектный подход позволяет создавать системы, 
которые воплощают пять атрибутов хорошо структурированных сложных сис¬ 
тем. Кроме того, можно назвать еще пять преимуществ, которые связаны с 
использованием объектного подхода. 

Во-первых, объектный подход позволяет в полной мере использовать 
выразительные возможности объектных и объектно-ориентированных языков 
программирования. Строустрап отмечал: «Не всегда очевидно, как в полной 
мере использовать преимущества такого языка, как C++. Существенно повы¬ 
сить эффективность и качество кода можно просто за счет использования 
C++ в качестве «улучшенного С» с элементами абстракции данных. Однако 
гораздо более значительным достижением является использование иерархии 
классов в процессе проектирования. Именно это называется OOD и именно 
здесь преимущества C++ продемонстрированы в наибольшей степени» [78]. 
Опыт показал, что использование таких языков, как Smalltalk, Object Pascal, 
C++, CLOS и Ada, без элементов объектного подхода является малоэффек¬ 
тивным. 

Во-вторых, использование объектного подхода существенно повышает 
качество разработки в целом и ее фрагментов [79].. Объектно-ориентирован¬ 
ные системы часто получаются более компактными, чем не объектно-ориен¬ 
тированные эквиваленты. А это означает не только уменьшение объема кода 
программ, но и удешевление проекта и большее удобство в планировании 
разработок. 

В-третьих, использование объектного подхода приводит к построению 
систем на основе стабильных промежуточных описаний, что упрощает про¬ 
цесс внесения изменений. Это дает системе возможность развиваться посте¬ 
пенно и не приводит к полной ее переработке в случае существенных изме¬ 
нений исходных требований. 
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В гл. 7 показано, что объектный подход уменьшает риск в разработке 
сложных систем прежде всего потому, что процесс интеграции растягивается 
во времени жизненного цикла системы. Объектный подход состоит из ряда 
хорошо продуманных этапов проектирования, что также уменьшает степень 
риска и повышает уверенность в правильности принимаемых решений. 

Наконец, объектный подход ориентирован на человеческое восприятие 
мира, или, по словам Рабсона, «многие люди, не имеющие понятия о том, 
как работает компьютер, находят вполне естественным объектно-ориентиро¬ 
ванный подход к системам» [80]. 


Авиационное оборудование 
Автоматизация учреждений 
Автоматизированное проектирование 
Автоматизированное обучение 
Автоматизированное производство 
Базы данных 
Гиперносители 

Компоненты программного обеспече¬ 
ния 

Контроль программного обеспечения 
Математический анализ 
Медицинская электроника 
Моделирование авиационной и кос¬ 
мической техники 
Музыкальная композиция 
Написание сценариев 
Нефтяная промышленность 
Обработка коммерческой информации 


Оживление 

Операционные системы 
Планирование инвестиций 
Подготовка документов 
Программные средства космических 
станций 

Проектирование интерфейса пользо¬ 
вателя 

Проектирование СБИС 
Распознавание образов 
Робототехника 
Системы телеметрии 
Системы управления и регулирова¬ 
ния 

Средства разработки программ 
Телекоммуникации 
Управление воздушным движением 
Управление химическими процессами 
Экспертные системы 


Примеры использования объектного подхода 

Возможность использования объектного подхода доказана для задач са¬ 
мого разного характера. Ниже приведен перечень областей применения, для 
которых реализованы объектно-ориентированные системы. Более подробные 
сведения для этих и других случаев можно найти в литературе, приведен¬ 
ной в библиографии. 

В настоящее время OOD — единственная методология, позволяющая 
справиться со сложностью, присущей самым большим системам. Однако, сле¬ 
дует заметить, что в ряде случаев применение OOD может оказаться неце¬ 
лесообразным но непринципиальным мотивам, как, например, неподготовлен¬ 
ность персонала или отсутствие соответствующих технических средств. 

Вопросы, требующие дальнейшего исследования 

Для более эффективного использования объектного подхода, предстоит 
ответить на следующие вопросы: 

* Что же такое классы и объекты? 
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* Как правильно идентифицировать классы и объекты для конкретного при¬ 
ложения? 

* Оптимальная система формального выражения решений, принимаемых в 
процессе OOD? 

* Что может помочь нам в процессе структурирования объектно-ориентиро¬ 
ванных систем? 

* Как организовать управление процессом 00D? 

Этим вопросам посвящены следующие пять глав. 

Заключение 

* Развитие программной технологии привело к созданию методов объектно- 
ориентированного анализа, проектирования и программирования, которые 
направлены на решение задачи программирования больших систем. 

* Существует ряд приемов программирования: процедурно-ориентированное, 
объектно-ориентированное, логически-ориентированное, ориентированное на 
правила и ориентированное на ограничения. 

* Объектный подход образует концептуальную основу для объектно-ориенти¬ 
рованной методологии; он включает принципы абстрагирования, ограниче¬ 
ния доступа, модульности, иерархии, типизации, параллелизма и устойчи¬ 
вости. 

* Абстрагирование означает выделение таких существенных характеристик 
объекта, которые отличают его от всех других объектов и, таким образом, 
четко определяют особенности данного объекта с точки зрения дальнейше¬ 
го его рассмотрения. 

* Ограничение доступа — процесс защиты отдельных элементов объекта, не 
затрагивающий существенных характеристик объекта как целого. 

* Модульность — свойство системы, связанное с возможностью ее декомпо¬ 
зиции на ряд тесно связанных модулей. 

* Иерархия — ранжированная или упорядоченная система абстракций. 

* Типизация — ограничение, предъявляемое классу объектов, препятствую¬ 
щее взаимозамене различных классов и в большинстве случаев сильно 
сужающее возможность такой взаимозамены. 

* Параллелизм — свойство, отличающее активные объекты от неактивных. 

* Устойчивость — свойство объектов существовать во времени и (или) в 
пространстве. 

* Применение объектного подхода позволяет создавать системы, обладающие 
пятью атрибутами хорошо структурированных сложных систем. 

Дополнительная литература 

Принципы объектного подхода впервые установлены в следующих рабо¬ 
тах: Jones [F, 1979], Williams [F, 1986]. В работе Kay Ph.D [F, 1969] оп¬ 
ределены направления развития OOP. Анализ механизма абстрагирования 
для программирования высокого уровня выполнен Shaw [J, 1984]. Теорети¬ 
ческие основы абстрагирования можно найти в работах Liskow, Guttag 
[Н, 1986], Guttag [J, 1980] и Hilfinger [J, 1982]. Parnas [F, 1979] заложил 
основы защиты информации. Особенности и роль иерархии приведены в ра¬ 
боте Pattee [J, 1973]. 

Имеется обширная литература по OOP. Хороший обзор объектных и 
объектно-ориентированных языков сделан Cardelli, Wegner [J, 1985] и 

Wegner [J, 1987]. Основы OOP хорошо освещены в следующих работах: 
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Stejic, Bobrow [G, 1986], Stroustrup [G, 1988], Nygaard [G, 1986]. Их раз¬ 
витие можно найти у Сох [G, 1986], Meyer [F, 1988], Schmucker [G, 
1986], Kim, Lochovsky [F, 1989]. Booch [F, 1981, 1982, 1986, 1987, 1989] 
формализовал методы OOD. Варианты этих методов можно найти в HOOD 
[F 1987] применительно к проекту Европейской космической станции, а 
также у Seidewitz, Stark, [F, 1988] GOOD. 

Подробная методика предлагалась Wirfs-Brock, Wilkerson [F, 1989] 
(отмечается значение реагирования), Constantine [F, 1989] и Wasserman 

[F, 1989]. Сюда же следует отнести работу Poss ]F 1987] по моделирова¬ 
нию в целом, работы Abelson, Sussman [Н 1985] по общим вопросам про¬ 
граммирования. Методы объектно-ориентированного анализа изложены Shlaer, 
Mellor [В, 1988], Bailin [В, 1988] и Coad, Yourdon [В, 1990]. 

Хорошие статьи по всем вопросам объектно-ориентированного подхода 
можно найти в работах Peterson [G, 1987], Schriver, Wegner [G, 1987]. 
Обширный материал по этой теме представляют конференции последних лет 
по объектно-ориентированным методам в компьютерной технике (ООО. 
Наиболее интересны конференции USENIX C++, OOPSLA (объектно-ориенти¬ 
рованные системы программирования, языки, практические приложения), 
ЕСООР (Европейская конференция по OOP). 



Глава 3 

Классы и объекты 

Использование объектно-ориентированной методологии для создания 
сложных программных систем подразумевает наличие базовых строительных 
блоков в виде классов и объектов. Выше было дано неформальное определе¬ 
ние этих двух элементов. В данной главе природа классов и объектов рас¬ 
сматривается более подробно. 

3.1. ОБЪЕКТ 

Что является объектом 

Способностью к распознаванию объектов физического мира человек 
обладает с раннего возраста. Ярко окрашенный мяч привлекает внимание 
ребенка, но, если спрятать мяч, ребенок, как правило, не пытается его ис¬ 
кать: как только предмет покидает поле зрения, он перестает для него су¬ 
ществовать. Только в возрасте около одного года у ребенка появляется 
представление о предмете. Покажите мяч годовалому ребенку и спрячьте 
его: обычно ребенок начинает искать спрятанный предмет. Ребенок связыва¬ 
ет понятие предмета с постоянством и индивидуальностью независимо от 
действий над этим предметом [1 ]. 

Выше объект был определен как осязаемая реальность, имеющая четко 
определяемое поведение. С точки зрения восприятия человеком объект 
можно определить одним из следующих способов: 

* Осязаемый и (или) видимый предмет. 

* Нечто, воспринимаемое мышлением. 

* Нечто, на что направлено мысль или действие. 

Таким образом, мы расширили неформальное определение объекта, 
привязав его к окружающей действительности и определив его 
существование во времени и пространстве. Термин «объект» в программном 
обеспечении впервые введен в языке Simula и означал какой-либо аспект 
моделируемой реальности [2]. 

Объектами реального мира являются не только те объекты, которые ин¬ 
тересны с точки зрения проектирования программных систем. Для отраже¬ 
ния механизмов поведения объектов на верхнем уровне абстракции в про¬ 
цессе проектирования программы вводятся специальные виды объектов [3]. 
Это приводит нас к более четкому определению, данному Смиттом и Токе- 
ем: «Объект представляет собой особый опознаваемый предмет, блок или 
сущность (реальную или абстрактную), имеющую важное функциональное 
назначение в данной предметной области» [4]. В еще более общем плане 
объект может быть определен как нечто, имеющее четко очерченные грани¬ 
цы [5]. 

Представим себе завод, на котором создаются композитные материалы 
для таких разных целей, как велосипедные рамы и крылья самолетов. Заво- 
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ды часто разделяются на цеха: механический, химический, электрический и 
т.д. Цеха подразделяются на участки, на каждом из которых несколько еди¬ 
ниц оборудования, таких, как штампы, прессы, станки. На производствен¬ 
ных линиях можно увидеть множество емкостей с исходными материалами, 
из которых с помощью химических процессов создаются блоки композитных 
материалов, являющихся в свою очередь основой для конечного продукта — 
велосипедных рам или крыльев самолета. Каждый осязаемый предмет может 
рассматриваться как объект. Токарный станок имеет, четко очерченные гра¬ 
ницы, которые отделяют его от обрабатываемого на этом станке композитно¬ 
го блока; рама велосипеда в свою очередь имеет четкие границы по отно¬ 
шению к участку с оборудованием. 

Существуют такие объекты, для которых определены явные границы, но 
сами объекты представляют собой неосязаемые события или процессы. 
Например, химический процесс на заводе: его границы явно определены 
взаимодействием компонентов, которые в течение определенного времени ве¬ 
дут себя известным образом. Аналогично система CAD/CAM позволяет опре¬ 
делять линию пересечения сферы и куба. Хотя эта линия не существует от¬ 
дельно от сферы и куба, она остается самостоятельным объектом в системе 
и ее границы четко определены. 

Объект обладает состоянием, проявляет четко выраженное поведение и 
индивидуальность. Объекты могут быть осязаемыми, но иметь размытые фи¬ 
зические границы. Например, реки, туман или толпы людей. Подобно тому, 
как взявший в руки молоток начинает видеть во вес і окружающем только 
объекты для забивания, проектировщик с объектно-ориентированным мышле¬ 
нием начинает воспринимать весь мир в виде объектов. Разумеется, такой 
взгляд несколько упрощен, так как существуют понятия, явно не являющие¬ 
ся объектами. К их числу относятся атрибуты, такие, как время, красота, 
цвет, эмоции (например, любовь или гнев). Однако все перечисленное явля¬ 
ется свойствами, которые присущи объектам. Можно, например, утверждать, 
что некоторый человек (объект) любит свою жену (другой объект), или 
определенный кот (еще один объект) имеет серую шерсть. 

Таким образом, требование иметь четкие границы не является достаточ¬ 
ным, чтобы отделить один объект от другого или дать оценку качества абс¬ 
тракции. На основе имеющегося опыта можно дать следующее определение: 

Объект обладает состоянием, поведением и индивидуальностью; 
структура и поведение схожих объектов определяют общий для них класс; 
термины «экземпляр класса» и «объект» — взаимозаменяемы. 

Состояние 

Понятие «состояние». Рассмотрим, например, торговый автомат, разли¬ 
вающий напитки. Поведение такого объекта состоит в том, что после опу¬ 
скания в него монеты и нажатия кнопки автомат «выдает» выбранный напи¬ 
ток. Что произойдет, если сначала будет нажата кнопка выбора напитка, а 
потом уже опущена монета? Большинство автоматов при этом никак не 
реагируют, так как действия человека не соответствуют заложенным в них 
правилам. Предположим, что пользователь автомата не обратил внимание на 
предупреждающий сигнал «Сделайте правильный выбор» и опустил в авто¬ 
мат еще одну монету. В большинстве случаев автоматы спокойно «проглаты¬ 
вают» такие монеты. 

Итак, поведение объекта определяется последовательностью совершаемых 
над объектом действий. Такая зависимость поведения во времени объясняет- 
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ся наличием данных о состоянии объекта в его структуре. Для торгового ав¬ 
томата, например, существенными являются данные о количестве опущенных 
монет до нажатия кнопки выбора напитка. Кроме того, важно знать об 
имеющемся выборе напитков и их количестве. 

На основе этого примера дадим следующее определение: 

Состояние объекта характеризуется перечнем всех возможных (обыч¬ 
но статических) свойств данного объекта и текущими значениями (обыч¬ 
но динамическими) каждого из этих свойств. 

Одним из свойств торгового автомата является также способность при¬ 
нимать монеты. С другой стороны, этому свойству соответствует динамиче¬ 
ское значение, характеризующее количество принятых монет, от которого 
зависит действие автомата. Число монет увеличивается по мере их опуска¬ 
ния в автомат и уменьшается во время обслуживания при извлечении мо¬ 
нет. В некоторых случаях значения Свойств объекта могут быть статически¬ 
ми (например, заводской номер автомата), поэтому в данном определении 
использован термин «обычно динамические». 

К числу свойств объекта относятся присущие ему или приобретаемые 
характеристики, черты, качества или способности, делающие данный объект 
самим собой. Например, для подъемника характерным является то, что он 
сконструирован для подъема и спуска, но не для горизонтального перемеще¬ 
ния. Перечень свойств объекта является, как правило, статическим, посколь¬ 
ку эти свойства составляют неизменяемую основу природы объекта. 
Выражение «как правило» означает, что в ряде случаев состав свойств объ¬ 
екта может изменяться. Примером может служить робот с возможностью са¬ 
мообучения. Робот первоначально может определить некоторое препятствие 
как статическое, а затем определить, что это дверь, которую можно откры¬ 
вать. В этой ситуации по мере получения новых знаний изменяется созда¬ 
ваемая роботом концептуальная модель объекта. 

Все свойства объекта характеризуются значениями их параметров. Эти 
значения могут быть простыми количественными характеристиками, а могут 
означать другой объект. Состояние подъемника может описываться числом 3, 
означающим номер этажа, на котором подъемник в данный момент находит¬ 
ся. Для торгового автомата состояние объекта включает множество других 
объектов, например имеющиеся в наличии смеси для приготовлении напит¬ 
ков. Эти смеси являются самостоятельными объектами независимо от торг¬ 
ового автомата (так как могут существовать самостоятельно) и над ними 
можно совершать определенные действия. 

Таким образом, мы установили различие между объектами и простыми 
величинами: простые количественные характеристики (например, числа) яв¬ 
ляются «постоянными, неизменными и неприходящими», тогда как объекты 
«существуют во времени, изменяются, имеют внутреннее состояние, преходя¬ 
щи и могут создаваться, разрушаться и разделяться» [6]. 

Тот факт, что всякий объект характеризуется состоянием, означает, что 
он занимает определенное пространство (физически или в памяти компью¬ 
тера). 

Примеры состояния. Предположим, что на языке C++ нам нужно со¬ 
здать регистрационные записи о персонале. Можно сделать это следующим 
образом: 



Объект обладает состоянием, проявляет четко выраженное поведение 
и индивидуальность. 
struct PersonnelRecord 
{ 

char ’name [100]; 

int socialSecurityNumbcr; 

char ‘department [10]; 

float salary; 

}; 

Каждая компонента в приведенной структуре обозначает конкретное аб¬ 
страктное свойство. Объявление определяет не объект, а класс, поскольку 
оно не отражает какой-либо реальности. Для того чтобы создать объекты 
данного класса, необходимо дать следующее: 

PerconnelRecord deb, dave, karen, jim, tom, denise; 

В данном случае объявлено шесть различных объектов, каждый из ко¬ 
торых занимает определенный участок в памяти. Хотя свойства этих объек¬ 
тов являются общими (их состояние представляется единообразно), в памяти 
объекты не пересекаются и занимают каждый свое место. На практике при¬ 
нято ограничивать доступ к элементам состояния объекта, а не делать их 
общедоступными, как в предыдущем определении класса. С учетом сказан¬ 
ного изменим данное определение следующим образом: 
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int employeeSocialSecurityNumbcr О const; 

char 'employeeDepartment () const; 

protected: 

void setEmployeeName (char *name); 

void setEmployeeSocialSecurityNumber (int number); 

void setEmployeeDeparlment (char 'department); 

void setEmployeeSalary (float salary); 

float employeeSalary 0 const; 

char 'name [100]; 

int sociatSecurityNumber; 

char *department[10]; 

float salary; 

}; 

Новое определение сложнее, но во многих отношениях содержательнее 
прежнего. В частности, в новом определении осуществлена защита для до¬ 
ступа к данным со стороны других объектов. Если структура этого класса 
будет в дальнейшем изменена, код придется перекомпилировать, но семанти¬ 
чески другие объекты не будут зависимы от этих изменений (т.е. их код 
сохранится). Кроме того, решается также проблема занимаемой объектом па¬ 
мяти за счет явного определения операций над объектами данного класса. В 
частности, все объекты-пользователи могут узнать имя, номер страховки, 
место работы, но только ограниченному кругу объектов разрешено устанав¬ 
ливать значения указанных параметров. Не для всех объектов разрешен до¬ 
ступ к параметру, характеризующему заработную плату. Другое достоинство 
последнего определения связано с возможностью его переопределения. В 
предыдущем разделе уже было показано, что механизм наследования позво¬ 
ляет переопределить абстракцию и специализировать ее содержание. 

В заключение скажем, что внутри каждого объекта хранятся в защи¬ 
щенном виде элементы, отражающие его состояние, и состояние всей систе¬ 
мы в целом распределено между объектами. 

Поведение 

Понятие «поведение». Объекты не существуют изолированно, а подвер¬ 
гаются воздействию или сами воздействуют на другие объекты. 

Поведение характеризует то, как объект воздействует или подверга¬ 
ется воздействию других объектов с точки зрения изменения состояния 
этих объектов и передачи сообщений. 

Другими словами, «поведение объекта полностью определяется его дей¬ 
ствиями» [7 ]. 

Операцией называется определенное воздействие одного объекта на дру¬ 
гой с целью вызвать соответствующую реакций). Например, объект-пользова¬ 
тель может активизировать операции Add и Pop для того, чтобы дать оче¬ 
редному объекту приращение или сократить его. Существует также операция 
Length_Of, которая позволяет определить размер объекта, но не может изме¬ 
нить значение этого размера. Применительно к таким языкам программиро¬ 
вания, как Smalltalk, принято говорить о передаче сообщений между объек¬ 
тами В основном понятие «сообщение» совпадает с понятием «операции» 
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над объектами, но механизм их действий различен. В дальнейшем эти два 
термина используются как синонимы. 

Как правило, в объектных и объектно-ориентированных языках опера¬ 
ции, выполняемые над данным объектом, называются методами (методиче¬ 
ской частью объекта) и входят составной частью в определение класса. В 
языке C++ для этих целей используется термин « функция-элемент *. 

Примеры поведения. На языке Ada опишем класс, определяющий оче¬ 
редь: 

type Item is private; 
package Simple_Queue is 

type Queue is limited pri 
procedure Copy 

procedure Clear 
procedure Add 

procedure Pop 
function Is_Equal 

function Length_Of 
function Is_Empty 
function Front_Of 
generic 

with procedure 

procedure Iterate 
Overflow 
Underflow 

end Slmple_Queue; 

Приведенный тип Queue означает класс, но не объект. Поскольку мы 
имеем дело с обобщением (пакет типа generic), то класс будет параметризо¬ 
ванным. Чтобы определить объекты очереди (целые значения), необходимо 
определить параметры в данном обобщенном пакете: 
package Integer_Queue is new Simple_Queue (item->Integer>; 

Затем определим четыре объекта данной очереди: 

А, В, С, D : Integer_Queue.Queue; 
use Integer_Queue; 

Теперь этими объектами можно управлять: 

Addri, To_The_Queue->A); 

Add О, To_The_Queue->A); 

Add (5, To_The_Queue->A); 

copy (From_The_Queue->A, To_The_Queue->B); 

Pop(B); 

Pop(B); 


(From_The_Queue 

To_The_Queue 

(The_Queue 

(The_Item 

To_The_Queue 

<The_Qucue 

(Left 

Right 

(The_Queue 

(The_Queue 

(The_Queue 




in Queue; 

in Queue) return Boolean; 
in Queue) return Natural; 
in Queue) return Boolean; 
in Queue) return Item; 


Process (The_Item : in Item; 

Continue ; out Boolean); 
(Over_The_Queue ; in Queue); 
; exception; 

; exception; 
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Выполнение указанных операторов приведет к тому, что очередь А бу¬ 
дет состоять из трех компонент (начиная с номера 1), а очередь В — из 
одной компоненты (начиная с номера 3). Каждый из объектов имеет при 
этом свое состояние, Определяющее их поведение. 

Понятие «операция». Из практики известно пять основных видов опера¬ 
ций над объектами. Ниже приведены наиболее распространенные операции: 

* Модификатор Операция, которая изменяет состояние объекта путем 

записи или доступа 

* Селектор Операция, дающая доступ для определения состояния 

объекта без его изменения (операция чтения) 

* Итератор Операция доступа к содержанию объекта по частям 

(в определенной последовательности) п 

Поскольку логика этих операций весьма различна, считается полезным 
при кодировании отметить эти различия. Так, при описании пакета Simple- 
Queue вначале определены все модификаторы (в виде процедур Copy, Clear, 
Add и Pop), затем все селекторы (в виде функций Is_Equal, Lenght_of, 
Is_Empty и Front_of) и в последнюю очередь итераторы (обобщенная проце¬ 
дура Iterate). 

В языках Smalltalk, C++ и CLOS определяются еще два вида операций: 

* Конструктор Операция создания и (или) инициализация объекта 

* Деструктор Операция разрушения объекта и (или) освобождение 

занимаемой им памяти 

В языке C++ конструктор и деструктор составляют часть описания клас¬ 
са, тогда как в Smalltalk и CLOS эти операторы определены в протоколе 
метакласса (т.е. класса классов). 

В языке Smalltalk операции могут быть только методами, так как про¬ 
цедуры и функции вне классов в этом языке определять не допускается. 
Напротив, в языках Object Pascal, C++, CLOS и Ada допускается описывать 
операции как независимые от объектов подпрограммы. Такие общедоступные 
процедуры и функции служат в качестве операций над объектами или объ¬ 
ектами одного или разных классов. Общедоступные процедуры группируются 
по отношению к классам, для которых они создаются. Это дает основание 
называть такие пакеты процедур утилитами класса. Например, на основе 
выше определенного пакета Integer_Queue можно дать описание следующей 
процедуры в отдельном пакете утилит класса: 

procedure pop_Until_Item_Found (The_Queue : in out Integer_Queue.Queue; 

The_Item : in Integer); 


Item_Not_Found : exception; 


Липман дал несколько иную классификацию: функции управления, функции реализации, 
вспомогательные функции и функции доступа [8]. 
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Цель такой операции состоит в последовательном исключении элементов 
очереди до тех пор, пока не будет обнаружен заданный элемент. Если оче¬ 
редь окажется пустой до того, как будет обнаружен заданный элемент, то 
имеет место особая ситуация. Данная операция йе является примитивной, 
она включает операции, входящие в класс Simple_Queue. 

Таким образом, любой метод является операцией, но не любая опера¬ 
ция является методом, так как могут иметь место общедоступные (свобод¬ 
ные) процедуры. Практически большая часть операций определяется как ме¬ 
тодическая часть классов, хотя, как показано в следующем разделе, иногда 
целесообразно сделать иначе. Например, когда создается операция, воздейст¬ 
вующая на несколько объектов разных классов, нет оснований относить та¬ 
кую операцию ни к одному из классов. 

Совокупность всех методов и общедоступных процедур, относящихся к 
конкретному объекту, образует протокол этого объекта. Протокол объекта, 
таким образом, определяет оболочку поведения объекта, охватывающую его 
внутреннее статическое и внешнее динамическое проявления. 

Объекты как автоматы. Наличие внутреннего состояния объектов озна¬ 
чает, что порядок выполнения операций имеет существенное значение. Это 
позволяет представить объект в качестве сложного независимого автома¬ 
та [9]. Для ряда объектов такой временной порядок настолько существен, 
что наилучшим способом описания такого объекта является теория конечных 
автоматов. 

Объекты могут быть активными и пассивными. Активными является тот 
объект, который расположен в канале управления. Активный объект в об¬ 
щем случае автономен, т.е. он может реализовать свое поведение без воз¬ 
действия со стороны других объектов. Пассивный объект, напротив, может 
изменять свое состояние только под воздействием ч других объектов. Таким 
образом, активные объекты системы составляют канал управления. Если сис¬ 
тема имеет несколько каналов управления, то и активных объектов может 
быть множество. В последовательных системах в каждый момент времени 
существует только один активный объект (и соответственно только один ка¬ 
нал управления). 

Индивидуальность 

Понятие «индивидуальность». Кхошафиан и Копеланд предложили сле¬ 
дующее определение: 

«Индивидуальность — это такие свойства объекта, которые отлича¬ 
ют его от всех других объектов» [10]. 

Они отмечают, что «в большинстве языков программирования и баз 
данных для различения временных объектов, их взаимной адресации и 
идентификации используются имена переменных» [11]. Источником множе¬ 
ства ошибок в объектно-ориентированном программировании является невоз¬ 
можность отличить имя объекта от самого объекта. 

Примеры индивидуальности. Сделаем следующее определение на языке 
Object Pascal: 

TPaletteltem- object (Tobject) 
kid : Integer; 
kFrame : Rect; 

procedure TPaletteltem.Initialize (ID : Integer; Frame ; Rect); 
procedure TPaletteltem.Free; override; 
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procedure TPalettellem.Draw (Area : Reel); 

procedure TPaletteltem.Highlingt (FromHL, ToHL : IlLSlate); 

function TPaletleltem.IsMouseHit (TheMouse : Point) : Boolean; 

end; 


TPaletteltem является определением класса и должно быть приведено в 
разделе описания типов программного блока. 

Объявить объекты (экземпляры) такого класса можно следующим обра¬ 
зом; 

Item_l, Item_2, Item_3 ; TPaletteltem; 

Это объявление должно быть сделано в разделе переменных. 

В результате такого определения (рис. 3-1, а) в памяти резервируются 
три области (называемые в Object Pascal переменными-ссылками на объект) 
с именами Item_l, Item_2, Item_3, начальное значение которых не определе¬ 
но, т.е. в данный момент эти имена не связаны ни с какими объектами. 
Для создания самих объектов необходимо в явном виде использовать проце¬ 
дуру new: 

new(Item_l); new (Item_2); 

Выполнение каждой процедуры создает отдельный объект и связывает 
этот объект с переменной-ссылкой. Поскольку указанные процедуры не ини¬ 
циализируют состояние объекта, это нужно сделать специально: 

SetRect (ARect, 1, 1, 32, 32, ); 

Item_l .Initialize (1001, ARect); 

SetRect (ARect, 1, 33, 32, 64, ); 

Item_2.Initialize (1002, ARect); 

Результат выполнения приведенных выше операций показан на 
рис. 3—1, Ь. Свойство индивидуальности сохраняется даже при полном из¬ 
менении состояния. Это напоминает вопрос Зенона о том, остается ли река 
сама собой в процессе времени, хотя никогда уже прежняя вода не потечет 
по ней? Для примера выполним теперь следующие операторы: 

Item_2.kld 1003; 
new <Item_3); 

SetRect (ARect, 1, 33, 32, 64); 

Item_3.Initialize (1003, ARect); 

Объект, обозначенный Item_2, по-прежнему существует, хотя его состоя¬ 
ние изменилось. Был создан новый объект с имейем Item_3, отличный от 
Item_2, хотя их состояния одинаковы. Отметим, что выражение «объект, 
обозначенный именем Item_2*>, будет более верным, чем выражение «объект 
Item_2», но в дальнейшем двумя этими фразами будем обозначать одно и 
то же. Что произойдет, если выполнить следующий оператор: 
ltem_l Item_2; 
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Рис. 3-1. Пояснение понятия «индивидуальность объектов». 

Оказывается, что результат будет нежелательным, как видно из 
рис. 3-1, Ь. Во-первых, объект обозначенный ранее Item_l , становится те¬ 
перь недоступен; он навсегда потерян и превращен в обычный «мусор». 
Имена Item_l и Item_2 теперь обозначают один и тот же объект. Такая си¬ 
туация называется структурной неопределенностью и означает, что один 
объект имеет несколько имен (раздвоение). Структурная неопределенность 
может иметь опасные последствия, так как позволяет изменить состояние 
объекта через первое имя, скрыв этот факт от объектов, пользующихся дру¬ 
гим именем. Выполним следующий оператор: 

Item_l.kld.-1 004; 

Мы видим, что одновременно изменилось состояние объекта, обозначен¬ 
ного Item_2. 

Операции присваивания и тождество объектов. Структурная неопреде¬ 
ленность возникает из-за дублирования индивидуальности объектов путем 
присвоения им нового имени. В большинстве случаев такая двойственность 
просто недопустима. Поэтому очень важно уметь определять такие ситуации 




и семантически их предотвращать. В используемых нами языках для предот¬ 
вращения указанных ситуаций используются следующие операции присвое- 

* Smalltalk 

* Object Pascal 

* C++ 

* CLOS 

* Ada 

Чтобы скопировать объект и избежать структурной неопределенности, в 
языке Smalltalk введены методы shallowCopy (копирующий только объект) и 
deepCopy (копирующий объект, включая его состояние). В языке Object 
Pascal той же цели служат предопределенные методы Clone и ShallowClone. 
В языке C++ эту же роль выполняет оператор присвоения (который переоп¬ 
ределяется с целью обеспечения требуемой семантике). В языке CLOS и 
Ada необходимо явно определить операторы копирования для каждого клас¬ 
са. 

С вопросом присвоения тесно связан вопрос тождественности. Тождест¬ 
венность представляется достаточно простой концепцией, но может обозна¬ 
чать одну из двух вещей. Во-первых, тождественность можно понимать как 
использование двух имен для обозначения одного и того же объекта. Во- 
вторых, тождественность может обозначать наличие одинакового состояния у 
двух разных объектов. В примере на рис. 3-1, b оба варианта тождест¬ 
венности будут справедливы для ltem_l и Item_2. Однако для Item_2 и 
Item_3 истинным будет только второй вариант. 

В разных языках по-разному обозначается также условие тождественно¬ 
сти. Для проверки того, относятся ли два имени к одному объекту, исполь¬ 
зуются следующие операторы: 

* Smalltalk 

* Object Pascal 

* C++ 

* CLOS 

* Ada 




В Smalltalk и C++ эти операторы могут быть переопределены. Следую¬ 
щие операторы используются для проверки эквивалентности состояний двух 
объектов: 


* Smalltalk 

* Object Pascal 

* C++ 

* CLOS 

* Ada 


user defined 
user defined 
equalp 

user defined 
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Рис. 3-2. Отношение использования между объектами. 

Время существования объектов. Началом времени существования любо¬ 
го объекта является момент его создания (отведение участка памяти), а 
окончанием — момент изъятия отведенного участка памяти. Следующие ме¬ 
тоды используются для создания объектов: 

* Smalltalk new 

* Object Pascal new 

* C++ new 

* CLOS make-instance 

* Ada new 

В языке C++ создание объекта автоматически приводит к вызову конст¬ 
руктора для данного класса объектов. Smalltalk, C++ и CLOS позволяют пе¬ 
реопределить методы создания объектов. В C++ и Ada для создания объектов 
в свободном участке памяти (динамической области) применяется процедура 
new. В этих двух языках возможно также создание временного объекта пря¬ 
мо в программном стеке путем объявления переменной данного класса. 

Объект продолжает существовать до тех пор, пока он занимает место в 
памяти, даже если будет потеряна ссылка на этот объект. В языках 
Smalltalk и CLOS определены процедуры «сборки мусора», в процессе кото¬ 
рых автоматически разрушаются все объекты, лишенные ссылок на них. В 
языках C++ и Ada объекты, созданные в программном стеке, ликвидируются 
автоматически при переходе управления за пределы области действия пере¬ 
менной, связанной с данным объектом. Следующие методы используются для 
явного разрушения объектов: 
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* Smalltalk release 

* Object Pascal free 

* C++ delete 

* Ada delete 


В C++ при ликвидации объекта автоматически вызывается деструктор 
соответствующего класса. В C++ и Ada к объектам созданным в динамиче¬ 
ской области памяти может быть применен метод delete. Переопределение 
деструкторов допускается в языке Smalltalk и C++. 

3.2. ОТНОШЕНИЯ МЕЖДУ ОБЪЕКТАМИ 
Типы отношений между объектами 

Сами по себе объекты не представляют никакого интереса, только в 
процессе взаимодействия объектов между собой реализуется цель системы. 
По выражению Ингалса: «Вместо бессистемной кусочной обработки структур 
данных мы получаем объекты с ясным поведением, которые обращаются 
друг с другом по тщательно проработанному интерфейсу и выполняют нуж¬ 
ные действия» [12]. Рассмотрим, например, структуру самолета, которая оп¬ 
ределяется как «совокупность элементов, каждый из которых по своей при¬ 
роде стремится упасть на землю, но за счет совместных непрерывных уси¬ 
лий преодолевает эту тенденцию» [13]. Только за счет согласованных уси¬ 
лий всех компонентов самолета он имеет возможность летать. 

Отношения двух любых объектов основываются на предположении, что 
каждый объект имеет информацию о другом объекте, об операциях, которые 
над ним можно выполнять, и об ожидаемом поведении. Особый интерес для 
OOD представляют два типа иерархических соотношений объектов: 

* Отношение использования. 

♦ Отношение включения. 

Зейдевиц и Старк назвали эти два типа отношений отношениями стар¬ 
шинства и родства соответственно [14]. 

Отношение использования 

Отношение использования между объектами. Отношения использования 
между несколькими объектами проиллюстрированы на рис. 3-2. На этом ри¬ 
сунке линия между двумя условными объектами обозначает наличие отно¬ 
шений использования между ними и подразумевает возможность передачи 
сообщений по этой линии. На выносной части рисунка (увеличено) видно, 
что при использовании объектом AnEscalator Controller объекта AnEscalator 
первый посылает второму сообщение (отмечено стрелкой вдоль линии). 

Пересылка сообщений между объектами обычно однонаправленна, но 
возможны и двунаправленные связи. Каждый объект, включенный в отноше¬ 
ния использования, может выполнять следующие три роли: 

Объект может воздействовать на другие объек¬ 
ты, но сам никогда не подвержен воздействию 
других объектов; в определенном смысле соот¬ 
ветствует понятию активный объект 


Воздействие 
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Объект в этом случае может только подвергать¬ 
ся управлению со стороны других объектов, но 
никогда не выступает в роли воздействующего 
объекта 

Такой объект может выступать как в роли воз¬ 
действующего, так и в роли исполнителя; как 
правило, объект посредник создается для выпол¬ 
нения операций в интересах какого-либо актив¬ 
ного объекта или другого посредника 

Примеры отношений использования. Рассмотрим, например, химический 
процесс, ще имеются два клапана для впуска двух различных жидкостей в 
реактор и один выпускной клапан. Для протекания реакции необходимо 
плавно повысить температуру веществ до определенной величины, затем 
поддерживать ее в течение определенного времени, после чего охладить до 
комнатной температуры. Одной из ключевых абстракций в такой задаче яв¬ 
ляется нагреватель, класс которого определим на языке CLOS следующим 
образом: 

(defctess heater О О) 

(defmethod tum_on (<h heater))...) 

(defmethod turnoff (<h heater))...) 

(defmethod current_temperature (<h heater))...) 

Здесь дано определение класса heater и трех его методов. Реализация 
методов дается в краткой записи, поскольку подробности в данном случае 
несущественны. Для образования экземпляра данного класса необходимо дать 
следующее описание: 

(setq a_heater (make-instance ’heater)) 

Затем можно определить класс реактора (crucible): 

(defclaa crucible О 

((temperature : initform 0 :accessor set_point))) 

((defmethod set_temperature (<c crucible) (f float) (s integer)) 

(tum_on a_heater) 

(turn off a_heater) 

Реализация метода set.temperalure частично опущена для краткости. 
Этот метод имеет своей целью довести реактор с до температуры f за s се¬ 
кунд. Для достижения этой цели используются посылки сообщений на вклю¬ 
чение и отключение нагревателя (tum_on и turn_off соответственно). Для 
создания экземпляра объекта crucible необходимо следующее описание: 


90 

* Исполнение 

* Посредничество 


(setq a_cructble (make-instance ’crucible)) 
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Теперь мы определим класс клапана (valve) и создадим три объекта 
этого класса: 

(defdass valve О О) 

(setq v_l (make-instance ’valve)) 

(selq v_2 (make-instance ’valve)) 

(setq v_3 (make-instance ’valve)) 

Будем полагать, что методы, позволяющие открывать и закрывать кла¬ 
паны, определены. Наконец, необходимо ввести класс, соответствующий кон¬ 
троллеру процесса (process_controller), управляющему работой клапанов и 
реактора, и создать экземпляр объекта данного класса: 

(defclass process_controller О О) 

(defmethod start_process ((с process_controller))...) 

(setq a_process_controller (make-instant ’process_conlroller)) 

Посмотрим, что произойдет при следующем вызове метода: 

(start_process a_process_contrailer) 

Во-первых, будут сообщения от объекта с именем a_process_controller к 
объектам с именами value_l и value_2 (для открытия и последующего за¬ 
крытия этих двух клапанов), после чего будет передано сообщение 
set_temperature объекту a_crucible. Объект с именем a_crucible в свою оче¬ 
редь формирует сообщение 1игп_оп и turn_off для посылки объекту a_heater. 
Наконец, объект a_process_controllcr передает сообщение объекту value_3 для 
освобождения реактора от продукта. 

В приведенном примере объекты a_heater, value_l, value_2 и value_3 яв¬ 
ляются исполнителями: они получают команды от других объектов, а сами 
на другие объекты не воздействуют. Объекты a_crucible и a_process_controller 
являются посредниками, поскольку они подвергаются воздействию других 
объектов и сами являются воздействующими. 

Понятие синхронизации. При передаче сообщений от одного объекта к 
другому оба взаимодействующих объекта должны определенным образом син¬ 
хронизироваться. Для последовательных систем такая синхронизация, как 
правило, реализуется через вызовы подпрограмм. Однако в параллельных си¬ 
стемах ситуация гораздо сложнее, поскольку для многоканального управле¬ 
ния необходимо решить проблему исключительных ситуаций. Отсюда выте¬ 
кает еще один способ классификации объектов: 

* Объект-транслятор Пассивный объект, имеющий только один канал 

управления 

* Блокированный объект Пассивный объект, имеющий несколько каналов 

управления 

* Параллельный объект Активный объект, имеющий несколько каналов 

управления 
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Ниже в настоящей главе приводятся примеры только транслирующих 
объектов. 

Отношение включения 

Понятие отношения включения между объектами. Логично предполо¬ 
жить, что конкретный объект-подъемник состоит из других объектов, напри¬ 
мер из мотора и датчика перемещений. Другими словами, последние два 
объекта являются элементами состояния объекта-подъемника, как показано 
на рис. 3-3. 

Между отношениями включения и использования существует взаимная 
связь. Включение одних объектов в другие предпочтительнее в том плане, 
что при этом уменьшается число объектов, с которыми приходится опериро¬ 
вать на данном уровне описания. С другой стороны, использование одних 
объектов другими имеет преимущество: не возникает сильной зависимости 
между объектами, как в случае включения. В процессе проектирования не¬ 
обходимо тщательно взвешивать оба указанных фактора. 

Примеры отношений включения. При построении абстракций квартиры, 
очевидно, необходимо включить в нее кухню, ванную комнату, спальню и 
гостиную. На языке Smalltalk это записывается следующим образом: 

Object subclass: /Apartment 

instanceVariableNames: 'aKitchen aBathroom aBedroom aFamilyRoom’ 
classVariableNames: ’ ' 
poolDictionaries: ’ ’ 
category: ’Simulation’ 

При образовании каждого экземпляра объекта класса Apartment образу¬ 
ются и все составляющие его объекты-компоненты. Предполагая, что классы, 
соответствующие кухне, ванной, спальне и гостиной, уже определены, мы 
определим следующий метод, входящий в класс Apartment: 



Рис. 3-3. Отношение включения между объектами. 
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initialize 

«Initialize the apartment by creating its rooms.» 

aKitchen <— Kitchen new. 
aBathroom <— Bathroom new. 
aBedroom <— Bedroom new. 

FamilyRoom <— FamilyRoom new. 

Теперь приведем оператор, создающий и инициализирующий локальный 
объект класса Apartment: 

I anApartment I 

anApartment <— Apartment new initialize. 

В качестве побочного эффекта процедуры «инициализация» образуются 
все четыре объекта. По отношению к такому объекту, как Apartment, при¬ 
меняются термины сложный, составной или агрегатированный. 

3.3. СУЩНОСТЬ «КЛАСС» 

Что такое класс? 

Понятия класса и объекта настолько тесно связаны, что невозможно го¬ 
ворить об объекте безотносительно к его классу. Однако существует важное 
различие в этих двух понятиях. В то время как объект обозначает конкрет¬ 
ную сущность, определенную во времени и в пространстве, класс определяет 
лишь абстракцию, «выжимку» из объекта. Таким образом, можно говорить о 
классе «Млекопитающие», который включает общие характеристики для всех 
млекопитающих. Для указания на конкретного представителя млекопитаю¬ 
щих необходимо сказать «это млекопитающее» или «то млекопитающее». 

В общеупотребительных терминах можно дать следующее определение 
класса: «группа, множество или вид с общими свойствами или общим свой¬ 
ством, разновидностями, отличиями по качеству, возможностями или услови¬ 
ями» [15]. С точки зрения OOD дадим следующее определение класса: 

Класс — множество объектов, связанных общностью структуры и 
поведения. 

Любой объект является просто экземпляром класса. 

Что не является классом? Объект не является классом, хотя в дальней¬ 
шем мы увидим, что класс может быть объектом. Объекты, не связанные 
общностью структуры и поведения, не могут образовать класс, так как по 
определению они не связаны между собой .ничем, кроме их общей природы 
как объектов. 

Внешние и внутренние проявления класса 

Мейер [16] и Снайдер (Snyder) [17] высказали точку зрения о том, 
что программирование в основном — это вопрос «взаимодействия»: большая 
задача и составляющие ее функции разделяются на более мелкие с одновре¬ 
менным определением взаимодействия этих компонентов в системе. Наиболее 
очевидно эта идея обнаруживается в проектировании классов. 

Класс служит для представлении совокупности объектов общей структу¬ 
ры и общего поведения. В то время как отдельный объект существует конк- 
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ретно и играет в системе определенную роль, класс содержит описание 
структуры и поведения всех объектов, связанных отношением общности. Та¬ 
ким образом, класс выполняет роль своего рода соглашения о связях в от¬ 
ношении абстракции и всех ее реализаций. В языках со строгой типизацией 
имеется возможность выявления нарушений такого соглашения о связях во 
время компиляции. 

Это достигается за счет того, что в интерфейсной части описания клас¬ 
са содержатся необходимые данные о проектных решениях. Приняв такую 
точку зрения на программирование как на процесс контрактации, мы прихо¬ 
дим к явному разделению внутреннего и внешнего проявления класса. Ин¬ 
терфейсная часть описания класса соответствует его внешнему проявлению, 
подчеркивает его абстрактность, но скрывает структуру и особенности пове¬ 
дения. В первую очередь интерфейсная часть класса состоит из перечня 
действий, который допускает описание других классов, констант, переменных 
и особенностей, необходимых для полного определения данной абстракции. 
Реализация класса, напротив, составляет его внутреннее проявление и опре¬ 
деляет особенности поведения. В этой части раскрывается реализация тех 
операций, которые перечислены в интерфейсной части описания. 

Интерфейсная часть описания класса может быть разделена на три со¬ 
ставные части: 

* Общедоступная Та часть интерфейса класса, в которой даются опре¬ 

деления, «видимые* для всех объектов-пользователей 
данного класса 

* Защищенная Та часть интерфейса класса, в которой даются опре¬ 

деления, «видимые» только для объектов, относящихся 
к подклассам данного класса 

* Обособленная Та часть интерфейса класса, в которой даются опре¬ 

деления, «скрытые» для объектов всех других классов 

Полностью такое разделение интерфейса класса реализуется только в 
языке C++ (из числа языков, упоминаемых в данной книге). При необходи¬ 
мости возможно определение на языке C++ структур без ограничения досту¬ 
па. В Ada допускается выделение общедоступной и обособленной частей, но 
отсутствует описание защищенной части. В языках Smalltalk, Object Pascal и 
CLOS разделение интерфейса на части должно реализоваться путем програм¬ 
мных соглашений. 

Структура состояния объекта также требует определенного описания, 
которое, как правило, состоит в объявлении констант и переменных в обо¬ 
собленной части описания интерфейса. Это делает общую часть структуры 
объектов закрытой для доступа, и, следовательно, внесение в эту часть из¬ 
менений не отражается на функционировании объектов-пользователей. В 
языке Smalltalk указанная часть определений может быть только обособлен¬ 
ной. В языках C++, CLOS и Ada допускаются такие определения как в обо¬ 
собленной, так и общедоступной части интерфейса класса, а в Object Pascal 
структура класса всегда общедоступна. 

У внимательного читателя может возникнуть вопрос: почему структура 
объекта является частью интерфейса класса (пусть даже и обособленная), а 
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не входит в реализацию? Такое решение имеет чисто практический интерес: 
другое решение требует либо создании специальных аппаратных средств, ли¬ 
бо значительно усложнит компилятор. В частности, при обработке компиля¬ 
тором следующего определения на C++: 

Shape aShape; 

требуется точно знать необходимый размер памяти, отводимый для этого 
объекта. Если структура класса определена вне его интерфейса, необходимо 
точно определить реализацию класса для того, чтобы точно пользователи 
могли оперировать таким объектом. Это в принципе нарушает идею разделе¬ 
ния класса на внешнюю и внутреннюю части. 

Константы и переменные, составляющие структуру класса в различных 
языках, обозначаются разными терминами. В языке Smalltalk используется 
термин «переменная объекта*, в языке Object Pascal — «поле*, в C++ — 
«фрагмент объекта*, а в CLOS ... термин «слот» (соответственно instance 
variable, field, member object, slot). В дальнейшем эти термины мы будем 
использовать как синонимы и обозначать структуру состояния объекта. 

3.4. ОТНОШЕНИЯ МЕЖДУ КЛАССАМИ 
Типы отношений 

Рассмотрим сходства и различия классов для следующих объектов: цве¬ 
ты, маргаритки, красные розы, желтые розы и лепестки. Сделаем следую¬ 
щие выводы: 

* Маргаритка — вид цветка. 

* Роза — (другой) вид цветка. 

* Красная и желтая розы — разновидность розы. 

* Лепесток является частью обоих видов цветов. 

Из этого простого примера следует, что классы, как и объекты, не су¬ 
ществуют изолированно. Наоборот, структура классов для конкретной обла¬ 
сти формируется на основе ключевых абстракций этой области и их свя¬ 
зей [18]. Отношение между двумя классами следует рассмотреть по двум 
причинам. Во-первых, отношения классов могут указывать на какой-либо 
вид общности. Например, маргаритки и розы являются разновидностями цве¬ 
тов, имеют яркую окраску лепестков, сильный аромат и т.д. Во-вторых, от¬ 
ношения классов могут влиять на семантику связи между ними. Можно от¬ 
метить, что между красными и желтыми розами больше сходства, чем меж¬ 
ду розами и маргаритками, а между маргаритками и розами больше, чем 
между лепестками и цветами. 

Известно три основных типа отношений между классами [19]. Первый 
тип называется отношением «разновидность» и отражает степень общности. 
Например, фраза «роза является разновидностью цветов» означает, что роза 
является более специализированным подклассом класса цветов. Второй тип 
отражает агрегатирование объектов и называется отношением «составная 
часть». Так, например, лепесток — не разновидность цветка, а его состав¬ 
ная часть. Третий тип обозначает отношение ассоциативности, т.е. смысло¬ 
вую связь между классами, которые не связаны никакими другими типами 
отношений. Примером могут служить два достаточно независимых класса 
роз и маргариток, которые соответствуют объектам, пригодным для декора¬ 
тивного оформления обеденного стола. 



Класс обозначает множество объектов, имеющих общую структуру и 
общее поведение. 

Языки программирования реализуют несколько общих способов для от¬ 
ражения трех типов отношений между классами. В частности, объектные и 
объектно-ориентированные языки программирования реализуют в разных 
комбинациях следующие механизмы отношения классов: 

* Наследование. 

* Использование. 

* Представление. 

* Метаклассы. 

Особый подход к реализации отношений наследования называется деле¬ 
гированием (delegation), когда объекты рассматриваются в качестве прототи¬ 
пов (образцов), которые делегируют свое поведение другим объектам, огра¬ 
ничивая потребность в создании новых классов [20]. 

Отношения наследования составляют наиболее эффективный тип отно¬ 
шений и могут использоваться как для отражения общности, так и для от¬ 
ражения ассоциативности. На практике наследуемость не позволяет отразить 
все богатство отношений между ключевыми абстракциями данной предмет¬ 
ной области. Для описания агрегатирования необходимо реализовать отноше¬ 
ния использования. Далее следуют отношения представления, которые, подо¬ 
бно наследованию, охватывают обобщение и ассоциативность, но совершенно 
другим образом. Особым типом отношений являются метаклассы, которые 
реализуются далеко не всеми объектными и объектно-ориентированными 
языками программирования. Метакласс — это класс классов, позволяющий 
трактовать классы как объекты. 
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Отношение наследования 

Примеры отношений наследования между классами. Находящиеся в 
полете космические зонды посылают на наземные станции информацию о 
состоянии своих основных систем (например, источников энергоснабжения и 
двигателях) и измерения датчиков (датчики радиации, масс-спектрометры, 
телекамеры, фиксаторы столкновений с микрометеоритами и т.д.). Вся сово¬ 
купность передаваемой информации называется телеметрическими данными. 
Как правило, телеметрические данные передаются в виде пакетов, состоящих 
из заголовка (включающего временные метки и ключи для идентификации 
последующих данных) и нескольких фрагментов данных от подсистем и дат¬ 
чиков. Поскольку передаваемые данные строго упорядочены, напрашивается 
описание каждого вида таких данных в виде записей структурного типа. На 
языке C++ это выглядит так: 

struct Time { 

int elapsedDays; 

Int seconds; 

}; 

struct ElectricalData { 

Time timeStamp; 

int id; 

float fuelCelll Voltage, fuelCell2Voltage; 

float fuelCelll Amperes, fuelCell2Amperes; 

float currentPower; 


Однако такое описание имеет ряд недостатков. Во-первых, структура 
ElectricalData не защищена, т.е. объект-пользователь может вызвать измене¬ 
ние такой важной информации, как элемент id или current Power (мощ¬ 
ность, развиваемая двумя химическими батареями). Во-вторых, эта структу¬ 
ра является полностью открытой, т.е. при ее модификации (добавлении но¬ 
вых элементов в структуру или изменение типа существующих элементов) 
нужно корректировать работу объектов-пользователей. Придется заново ком¬ 
пилировать все описания, связанные каким-либо образом с этой структурой. 
Еще важнее, что внесение в эту структуру изменений может нарушить ло¬ 
гику отношений с объектами-пользователями, а следовательно, логику всей 
программы. Кроме того, приведенное описание структуры очень трудно для 
восприятия. По отношению к такой структуре можно выполнить множество 
различных действий (пересылка данных, вычисление контрольной суммы для 
определения ошибок и т.д.), но все эти действия не будут связаны с приве¬ 
денной структурой логически. В завершение предположим, что анализ требо¬ 
ваний к системе обусловил наличие нескольких сотен разновидностей теле¬ 
метрических данных, включая другие электрические параметры, предшеству¬ 
ющую информацию и замеры напряжения в разных контрольных точках си¬ 
стемы. Очевидно, что описание такого количества дополнительных структур 
превысит приемлемый уровень как с точки зрения повторяемости структур, 
так и с точки зрения числа функций их обработки. 

Подкласс может наследовать как структуру, так и поведение от своих 
суперклассов. Лучшим способом сохранения единства подхода к проекту яв¬ 
ляется создание для каждого вида телеметрических данных отдельного клас¬ 
са, что позволит защитить данные в каждом классе и увязать их с выпол¬ 
няемыми операциями. Этот же подход решает проблему избыточности описа- 
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Еще лучше и последовательнее построить иерархию классов, в которой 
на основе более общих классов с помощью наследования образуются более 
специализированные; например, следующим образом: 

class Telemetry Data { 
public: 

Telemetry Data 0; 

Telemetry Data (const Telemetry Data*); 
virtual -TelemetryData 0; 
virtual void send 0; 

Time currentTime 0 const; 

protected: 

int id; 

private: 

Time timeStamp; 


В этом примере введен класс, имеющий конструктор, деструктор и 
функции send и currentTime, видимые для всех объектов-пользователей. 

Элемент id определен в защищенной части описания и видим только 
для класса TelemetryData. В то же время общедоступная функция 
currentTime позволяет всем объектам получить значение timeStamp, но изме¬ 
нить его при этом невозможно. Теперь перепишем класс ElectricalData: 

class ElectricalData: public TelemetryData { 
public: 

ElectricalData (float vl, float v2, float al, float a2); 

ElectricalData (const ElectricalDatadr); 
virtual ~ ElectricalData 0; 

virtual void send 0; .. 

virtual float currentPower 0 const; 

protected: 

float fuelCelll Voltage, fuclCell2Voltagc, fucICcll I Amperes, fuclCell2Amperes; 

}; 


Этот класс образован наследованием класса TelemetryData, но исходная 
структура дополнена (четырьмя новыми элементами), а поведение определе¬ 
но (изменена функция send). Почему значение currentPower не реализовано 
в виде элемента структуры, как в предыдущем описании ElectricalData? Это 
не является необходимым, так как данное значение легко вычисляется кос¬ 
венным образом с помощью функции currentPower. 

Понятие простого наследования классов. Определено, что наследование 
— такое отношение между классами, когда один класс повторяет структуру 
и поведение другого ( простое наследование) или других (множественное 
наследование) классов. Класс, структура и поведение которого наследуются, 
называется суперклассом. Так, TelemetryData является суперклассом для 
ElectricalData. Производный от суперкласса класс называется подклассом по 
отношению к TelemetryData. Это означает, что наследование устанавливает 
между классами иерархию «по номенклатуре». В этом смысле ElectricalData 
является более специализированным классом от более общего TelemetryData. 
Мы уже видели, что в подклассе структура и поведение исходного супер¬ 
класса дополняются и переопределяются. Наличие такого механизма отлича¬ 
ет объектно-ориентированные языки проектирования от объектных. 
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Подкласс может наследовать структуру и поведение своего суперкласса. 

Отношения простого наследования от суперкласса TelemettryData показа¬ 
ны на рис. 3-4. Стрелками на рисунке показаны отношения типа «разновид¬ 
ность» или «является». В частности, CameraData — это разновидность класса 
SensorData, который в свою очередь является разновидностью суперкласса 
Telemetry Data. Такой же тип иерархии характерен для семантических сетей, 
которые часто используются специалистами по распознаванию образов и ис¬ 
кусственному интеллекту для организации баз знаний [21 ]. В главе 4 пока¬ 
зано, что правильная организация иерархии абстракций — это вопрос логи¬ 
ческой классификации. 

Можно ожидать, что для некоторых классов на рис. 3-4 будут созданы 
экземпляры объектов, а для других не будут. Наиболее вероятно образова¬ 
ние объектов из наиболее специализированных классов ElectricalData и 
SpectrometerData. Образование объектов из классов, занимающих промежу¬ 
точное положение, более общее значение (SensorData и даже 
TelemetryData) , менее вероятно. Такие классы, для которых не определены 
реализации объектов, называются абстрактными классами. На основе абст¬ 
рактных классов образуются подклассы, дополненные в структурной и глав¬ 
ным образом методической части. В языке Smalltalk допускается переопреде¬ 
ление метода в подклассе за счет использования метода 
SubclassResponsibility. При невозможности переопределения вызов такого ме¬ 
тода приводит к ошибке исполнения. В языке C++ метод абстрактного клас¬ 
са может быть заблокирован с помощью его инициализации в подклассе ну¬ 
левым (пустым) значением. Такой метод называется чистой виртуальной 
функцией, а механизмы языка допускают создание объектов, экспортирую¬ 
щих такие функции. 
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Самый общий класс в структуре классов называется базовым классом. 
В большинстве приложений базовых классов бывает несколько, и они отра¬ 
жают наиболее общие категории абстракций в конкретной предметной обла¬ 
сти. В некоторых языках программирования определен базовый класс самого 
верхнего уровня, который является единственным суперклассом для всех ос¬ 
тальных классов. 

В языке Smalltalk эту роль играет класс Object, а в Object Pascal — 
это TObject. В языке CLOS неявно определен класс standard-class в качест¬ 
ве единого суперкласса всех классов defclass; t является неявным суперклас¬ 
сом для standard-class и для большинства простых типов. В C++ общий ба¬ 
зовый класс аномален. 

Для любого класса обычно определяются два вида пользователей [22]: 

* Экземпляры данного класса. 

* Производные подклассы. 

Часто оказывается полезным различать интерфейс для этих двух. (Разно¬ 
видностей [23], чем объясняется наличие общедоступной, защищенной и 
обособленной части описания класса на языке C++: разработчик может четко 
разделить, какие элементы класса доступны для экземпляров, подклассов, 
для тех и других. В языке Smalltalk степень такого разделения меньше: эле¬ 
менты структуры «видимы» для подклассов, но не для экземпляров, а мето¬ 
дическая часть общедоступна (допускается определять методы в качестве 
обособленных, но это не обеспечивает защиту). В Object Pascal поля и ме¬ 
тоды общедоступны, а в CLOS слоты доступны для подклассов, а для экзем¬ 
пляров «видимость» контролируется квалификаторами :reader, :writer и 
:accessor (чтение, запись, доступ соответственно). 

Наследование подразумевает повторение структуры суперкласса. В 
предыдущем примере экземпляры класса ElectricalData содержат элементы 
структуры суперкласса (id и timeStamp) и элементы специализированного 
класса (fuelCelllVoltage, fuelCell2Voltage, fuelCelllAmperes, fuelCell2Amperes). 
Языки Smalltalk, Object Pascal, C++ и CLOS позволяют дополнять структуру 
суперкласса в подклассах. Однако в этих языках нельзя использовать для 
фрагмента данных уже существующее имя, так же как не допускается и со¬ 
кращение структуры суперкласса в подклассах. Между наследованием и ог¬ 
раничением доступа существует реальное противоречие. В процессе наследо¬ 
вания в значительной степени открывается строение суперкласса, т.е. для 
понимания строения конкретного класса нужно изучить все его суперклассы, 
включая в некоторой степени их внутреннее строение. 

Поведение суперклассов также наследуется. Применительно к объектам 
класса ElectricalData можно использовать операции currentTime (унаследована 
от суперкласса), currentPower (определена в суперклассе) и send (переопре¬ 
делена по отношению к суперклассу). В большинстве языков допускается не 
только наследование методов суперкласса, но также исключение, добавление 
новых и переопределение существующих. В Smalltalk, Object Pascal и CLOS 
любой метод суперкласса можно переопределить в подклассе (в языке CLOS 
это называется обобщенной функцией). В Object Pascal для переопределения 
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Рис. 3-4. Отношение простого наследования классов. 

метода принято использовать ключевое слово override в определении под¬ 
класса. В C++ степень управления этим свойством несколько выше. Функ¬ 
ция, объявленная виртуальной (функция send в предыдущем примере), мо¬ 
жет быть в подклассе переопределена, любая другая функция не может 
быть переопределена (как функция currentTime). 

Понятие простого полиморфизма. Функция send для класса 
TelemetryData может быть реализована следующим образом: 

void TelemetryData :: send 0 { 

// transmit the id 
// transmit the timeStamp 
>: 


Заметим, что класс, к которому относится данная функция, назван яв¬ 
но. Тело этой функции является неполным (выполняемые действия опреде¬ 
лены в виде комментариев), но сам пример демонстрирует факт возможно¬ 
сти отделения интерфейса метода от его реализации (в языке CLOS при 
объявлении метода неявно вводится обобщенная функция). Возвращаясь к 
реализации метода send в классе Electrical Data, напишем 

void ElectiicalData :: send О { 

TelemetryData ::send 0; 

// transmit the fuelCelUVoltage and the fuelCell2Voltage 
// transmit the fuelCelUAmperes and the fuelCell2Amperes 
// transmit the currentPower 


Такая реализация предусматривает выполнение операций, определенных 
в суперклассе, а затем дополнительной операции по пересылке данных соот¬ 
ветствующих данному специализированному классу. 
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Определим теперь экземпляры двух описанных выше классов (хотя для 
класса Telemetry Data это не типично): 

Telemetry Data telemetry; 

ElectricalData electrical (5.0, -5.0, 3.0, 7.0); 

При наличии объектов, обозначенных именами telemetry и electrical, да¬ 
дим следующее определение функции: 

void sendTelemetryData (TelemetryData &D) { 

D.send О; 

>. 


Что произойдет при выполнении двух следующих операторов? 

sendTelemetryData (telemetry); 
sendTelemetryData (electrical); 

В первом случае осуществляется пересылка данных id и timeStamp, а 
во втором кроме тех же данных пересылаются еще пять действительных чи¬ 
сел. Как это получается? Ведь тело функции SendTelemetryData состоит из 
единственного оператора D.Send О, который не отличается для класса D. 
Причина состоит в полиморфизме. Полиморфизм — это такой элемент тео¬ 
рии типизации, который позволяет использовать одно имя (параметр D) для 
обозначения объектов различных классов, имеющих общий суперкласс. 

В результате объект с таким именем может по-разному реагировать на 
выполнение общего набора операций. Карделли и Вегнер заметили, что 
«традиционные типизированные языки типа Pascal основаны на идее о том, 
что функции и процедуры, а следовательно, и операнды должны иметь оп¬ 
ределенный тип. Это свойство называется мономорфизмом т.е. каждая пере¬ 
менная и каждое значение относятся к одному определенному типу. В про¬ 
тивоположность мономорфизму полиморфизм допускает отнесение значений и 
переменных к нескольким типам» [24]. Впервые полиморфизм описал Стра- 
чи [25], который ввел особый вид полиморфизма, в котором символы, та¬ 
кие, как +, могут иметь различное значение. В настоящее время этот под¬ 
ход носит название «перегрузка» (overloading). Например, в языках C++ и 
Ada можно объявлять несколько процедур или функций, имеющих одинако¬ 
вое имя, но различающихся перечнем параметров, количеством и типом ар¬ 
гументов и возвращаемых значений. Тем же автором. введен термин «пара¬ 
метрический полиморфизм», который мы теперь называем просто полимор¬ 
физмом. 

При отсутствии полиморфизма код программы вынужденно содержит 
множество операторов варианта или переключения. Например, на языке 
Pascal невозможно образовать иерархию классов телеметрических данных; 
вместо этого придется определить одну большую вариантную запись, вклю¬ 
чающую все разновидности данных. Для выбора варианта нужно проверить 
значение параметра, связанного с типом записи. На языке Pascal процедура 
sendTelemetryData может быть написана следующим образом: 


Electrical - 1; 

Propulsion - 2; 

Spectrometer - 3; 
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procedure Send_Telemelry_Data (TheData: Data); 
begin 

case TheData.Kind of 

Electrical : SendElectricalData (TheData); 
Propulsion : SendPropulsionData (TheData); 


Чтобы ввести новый тип телеметрических данных, нужно модифициро¬ 
вать эту вариантную запись и расширить оператор варианта, который уп¬ 
равляет выбором варианта. В такой ситуации увеличивается вероятность 
ошибок и проект становится нестабильным. 

Наследование позволяет разделить различные разновидности абстракций, 
отказавшись от введения таких монолитных типов. Каплан и Джонсон отме¬ 
тили, что «полиморфизм наиболее целесообразен в тех случаях, когда не¬ 
сколько классов имеют одинаковые протоколы» [26]. Полиморфизм позволя¬ 
ет обойтись без больших операторов варианта, поскольку сами объекты со¬ 
держат сведения о типе данных. Возможна реализация наследования без по¬ 
лиморфизма, но эффективность такого механизма очень низка. Это видно 
на примере языка Ada, ще можно объявить производные типы, но из-за 
мономорфизма языка уже в период компиляции действительный тип опера¬ 
ций полностью определяется. Полиморфизм тесно связан с механизмом позд¬ 
него связывания. При полиморфизме связь метода и имени определяется 
только в процессе выполнения программ. В языке C++ программист имеет 
возможность управлять связью имен с методами. В частности, для реализа¬ 
ции позднего связывания метод объявляется виртуальным (фактическим) и, 
таким образом, для данной функции реализуется полиморфизм. Если объяв¬ 
ление виртуальности опущено, то метод полностью определяется во время 
компиляции и не может быть изменен позднее. Способ выбора выполняемо¬ 
го метода подробно описан в тексте, заключенном в рамку. 

Наследование и типизация. Рассмотрим переопределение функции send: 

void ElectricalData :: send О { 

TelemetryData ::send 0; 

// transmit the fuelCelll Voltage and the fuelCell2Voltage 
// transmit the fuelCelll Amperes and the fuelCell2Amperes 
// transmit the currentPower 

}: 


В большинстве объектно-ориентированных языков программирования до¬ 
пускается переопределение в подклассе метода, который был определен в су¬ 
перклассе. Из примера видно, что при переопределении метода принято ис¬ 
пользовать для него также имя, которое было дано в суперклассе. В языках 
Smalltalk и Object Pascal допускаются ссылки на метод непосредственного 
предка (суперкласса) с помощью ключевых слов super и in herited (соответ¬ 
ственно для Smalltalk и Object Pascal). В этих же языках определен специ¬ 
альный параметр self для указания на объект, связанный с данным методом. 
В языке C++ для обращения к методу суперкласса (любого суперкласса в 
пределах «видимости») перед именем метода следует указать имя такого су¬ 
перкласса. Для указания на сам объект в C++ существует специальный ука¬ 
затель this. Для достижения той же цели в языке CLOS определена функ¬ 
ция call-next-method. 
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Процесс вызова функции (метода) 

В традиционных языках программирования вызов подпрограмм явля¬ 
ется вполне определенной операцией. Например, в Pascal для вызова 
подпрограммы Р компилятор модифицирует стек, помещая в него опреде¬ 
ленные аргументы, после чего управление передается на начало кода 
подпрограммы Р. Однако в языках Smalltalk, Object Pascal, C++, CLOS 
процедура вызова подпрограммы реализуется более сложным динамиче¬ 
ским образом, поскольку класс объектов-операндов определяется только во 
время выполнения программы. Если добавить к этому механизм наследо¬ 
вания, то ситуация еще более усложняется. Наследование без полимор¬ 
физма мало отличается от обычного вызова подпрограммы, но наличие 
полиморфизма приводит к более сложным механизмам реализации. 

Рассмотрим следующую иерархическую структуру (рис. 3-5), в кото¬ 
рой имеется базовый класс Shape и три подкласса с именами Circle, 
Triangle и Rectangle. Для класса Rectangle определен в свою очередь под¬ 
класс Solid Rectangle. Предположим, что в классе Shape определена пере¬ 
менная theCenter (соответствующая координатам X и Y центра изображе¬ 
ния в определенной системе координат), а также следующие операции: 

* Set Center Установить координаты (X и Y) центра 

* Draw Сформировать изображение 

* Center Возвращает значение координат (X и У) центра. 

Операции Set Centre и Center являются общими для всех подклассов 
и не требуют переопределения. Однако операция Draw для каждого под¬ 
класса является индивидуальной и должна быть определена заново (пере¬ 
определена). Поскольку класс Shape является абстрактным, тело метода 
Draw является пустым (это чисто виртуальная функция по терминологии 
C++). 

Класс Circle включает переменную the Radius и соответственно опе¬ 
рации для установки и чтения значения этой переменной. Для этого 
класса операция Draw формирует изображение окружности заданного ра¬ 
диуса с центром в определенной точке (X и Y). В классе Rectangle та¬ 
ким же образом введены переменные the Height и the Width и операции 
установки и чтения их значений. Операция Draw в данном случае фор¬ 
мирует изображение прямоугольника заданной высоты и ширины с цент¬ 
ром в заданной точке (X и Y). Подкласс Solid Rectangle наследует все 
особенности класса Rectangle, но операция Draw в этом подклассе пере- 
определейа. 

В классе Solid Rectangle вначале выполняется операция Draw по ме¬ 
тоду суперкласса (Rectangle), а затем изображение дополнительно закра¬ 
шивается. На рис. 3-6 показаны отношения между, указанными классами 
с учетом полиморфизма. Мы видим здесь однородный список изображе- 



Классы и объекты 


105 


ний, полагая, что список может содержать объекты подклассов, входящих 
в класс Shape. Предположим, что некоторый объект-пользователь хочет 
сформировать всю совокупность изображений из числа находящихся в 
списке. Будем делать это итеративно, проходя по списку и выполняя ме¬ 
тод Draw для каждого объекта. В этом случае компилятор не сможет со¬ 
здать статический код вызова операции Draw, так как класс объектов в 
списке заранее не определен. 

Поскольку язык Smalltalk является нетипизированным, вызов опера¬ 
ций будет полностью динамическим. Когда объект-пользователь сформиру¬ 
ет сообщение Draw применительно к объекту, встретившемуся в списке, 
будет происходить следующее: 

* Соответствующий объект осуществляет поиск данного сообщения в сло¬ 
варе своего класса. 

* Если сообщение найдено, вызывается нужный код для найденного ло¬ 
кального метода. 

* Если в своем классе сообщение нужного вида не найдено, поиск пере¬ 
мещается в суперкласс. 

Этот процесс выполняется для всей иерархии суперклассов, пока не 
будет найдено нужное сообщение или процесс не достигнет базового 
класса Object. Если и в последнем случае сообщение не будет найдено, 
Smalltalk формирует сигнал о наличии ошибки doesNotUnderstand. 

Основную роль в приведенном алгоритме играет словарь сообщений, 
являющийся составной частью каждого класса, скрытой от обьектов-поль- 
зователей. 



Рис. 3-5. Схема класса Shape. 




Рис. 3-6. Схема объекта Shape. 


Такой словарь создается вместе с образованием класса и содержит 
информацию о всех методах, которые могут применяться к объектам-эк¬ 
земплярам данного класса. Поиск в словаре сообщений занимает опреде¬ 
ленное время, поэтому в языке Smalltalk поиск метода занимает в 1,5 
раза больше времени, чем обычный вызов подпрограммы. 

Во всех коммерческих версиях языка Smalltalk реализуется оптимиза¬ 
ция процесса поиска за счет помещения словаря сообщений в кэш-па¬ 
мять. Это улучшает временные характеристики на 20-30% [27]. Опера¬ 
ция Draw, определенная в подклассе Solid Rectangle представляет собой 
особый случай. Мы уже отмечали, что при данной реализации метода 
Draw вначале делается вызов метода Draw определенного в суперклассе 
Rectangle. В Smalltalk для вызова метода суперкласса используется ключе¬ 
вое слово Super. Декларирование метода Draw вместе с Super приводит к 
тому, что алгоритм поиска начинается не с данного класса, а сразу с су¬ 
перкласса. 

Исследования Дейтча дают основание полагать, что время поиска 
при реализации механизма полиморфизма может быть сокращено на 
85%, а передача сообщений при этом сравняется по времени с обычным 
временем процедур [28]. Даф замечает, что в таких ситуациях програм¬ 
мист часто подразумевает реализацию раннего связывания классов объек¬ 
тов [29]. К сожалению, в нетипизированных языках отсутствуют средст¬ 
ва, позволяющие сообщить компилятору о предположениях программиста. 

В строго типизированных языках типа Object Pascal и C++ такая 
возможность реализуется. В этих языках алгоритм вызова методов не¬ 
сколько отличается от описанного выше и позволяет сократить, где воз¬ 
можно, время поиска, сохранив при этом свойства полиморфизма. 

В C++ операции, подразумевающие позднее связывание, объявляются 
виртуальными (Virtual), а все остальные обрабатываются компилятором 
как обычные вызовы подпрограмм. В нашем примере метод Draw должен 
быть виртуальной функцией, а методы Set Center и Center — обычными 
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(поскольку они не переопределяются). Невиртуальные методы могут быть 
объявлены подставляемыми (in Line), при этом соответствующая процеду¬ 
ра целиком включается в код программы, создавая эффект макроопреде¬ 
ления. Однако макроопределение приводит к дополнительным затратам 
памяти. 

Для управления реализацией виртуальных функций в C++ использу¬ 
ется концепция ѵ-таблиц, которые создаются для каждого объекта при 
его образовании (т.е. для фиксированного класса объекта). Такая таблица 
содержит список указателей на виртуальные функции. Например, при со¬ 
здании объекта класса Rectangle ѵ-таблица будет содержать графу для 
виртуальной функции Draw, содержащую указатель на ближайшую по 
иерархии реализацию функции Draw. Если в классе Shape определена 
виртуальная функция Rotate, которая в классе Rectangle не переопределе¬ 
на, то соответствующий указатель для Rotate будет связан с классом 
Shape. В соотвествии с этим осуществляется поиск нужной функции во 
время исполнения программы: происходит косвенное обращение через со¬ 
ответствующий указатель к функции объекта и сразу реализуется пра¬ 
вильно выбранный код без всякого поиска [30]. 

Операция Draw в классе Solid Rectangle представляет собой особый 
случай в языке C++. Чтобы реализовать метод Draw, определенный в су¬ 
перклассе, применяется специальный оператор, указывающий на место 
определения функции. Это выглядит следующим образом: 

Rectangle :: Drawl); 

Исследование Страустрапа показали, что вызов виртуальной функции 
по. эффективности немного уступает вызову обычной функции [31 ]. Для 
простого наследования вызов виртуальной функции требует дополнительно 
выполнения трех-четырех операций адресации по отношению к обычному 
вызову; при множественном наследовании число таких дополнительных 
операций адресации составляет пять или шесть. 

Существенно Сложнее выполняется поиск нужных функций в языке 
CLOS, здесь используются дополнительные квалификаторы: :before, :after, 
:around. Операции определяются как обобщенные функции и каждая та¬ 
кая функция может быть связана с множеством методов. Наличие мно¬ 
жественного полиморфизма еще более усложняет проблему. При выборе 
нужного метода в языке CLOS, как правило, реализуется следующий ал¬ 
горитм: 

* Определяется тип аргументов. 

* Устанавливается множество допустимых методов. 

* Методы сортируются в направлении от наиболее специализированных к 
более общим и в соответствии со списком старшинства классов. 

* Выполняются вызовы всех методов с квалификатором :before. 

* Выполняется вызов наиболее специализированного первичного метода. 

* Выполняются вызовы всех методов с квалификаторами :after. 

* Возвращается значение первичного метода [32]. 
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Язык С LOS реализует особый прием программирования метаобьектов, 
который позволяет переопределять любые алгоритмы, используемые для 
управления обобщенными функциями. На практике, однако, используют в 
основном системные алгоритмы в исходном виде. Как справедливо отме¬ 
тили Уинстон и Хорн: «Алгоритмы, используемые в языке CLOS, слож¬ 
ны, и даже кудесники программирования стараются не вникать в их осо¬ 
бенности, так же как физики предпочитают иметь дело с механикой 
Ньютона, а не квантовой механикой» [33]. 


На практике часто приходится обращаться к методам суперклассов. 
Подклассы играют роль расширителя возможностей суперклассов. В языке 
CLOS явно определены квалификаторы before, after, around, определяющие 
разновидность метода. Метод без квалификатора считается исходным (глав¬ 
ным) и определяет в основном поведение объекта. Методы с квалификатора¬ 
ми before и after вызываются соответственно до и после главного метода с 
помощью функции call-next-method. 

Все подклассы на рис. 3-4 являются подтипами исходного класса, т.е. 
экземпляры классов ElectricalData и TelemetryData являются подтипами. Для 
всех строго типизированных языков, включая Object Pascal и C++, является 
характерным наличие параллелизма в отношениях типизации и насле¬ 
дования. К языкам Smalltalk и CLOS это относится в гораздо меньшей сте¬ 
пени из-за отсутствия в них типизации. 

Параллель между типизацией и наследованием следует ожидать при со¬ 
здании иерархии по принципу обобщения/специализации, ще механизм на¬ 
следования позволяет реализовать смысловые связи между абстракциями. 
Рассмотрим следующее описание на C++: 

TelemetryData telemetry; 

ElectrycalData electrical (5.0, -5.0, 3.0, 7.0); 

Следующий оператор присвоения является правильным: 
telemetry - electrical; //electrical is a subtype of telemetry 

Но следующий оператор является ошибкой: 
electrical - telemetry; // Illegal: telemetry is not a subtype of electrical 

Можно сделать заключение, что присвоение объекту Y значения объекта 
X допустимо, если тип объекта X совпадает с типом объекта Y или являет¬ 
ся его подклассом. 

В большинстве строго типизированных языков программирования допу¬ 
скается преобразование значений из одного типа в другой, но только в тех 
случаях, коща между двумя типами существуют отношения вида класс/под¬ 
класс. Например, в языке C++ допускается введение операторов явного пре¬ 
образования типов (классов), называемого приведением типов (type cast). В 
языке Object Pascal аналогичный механизм носит название «привязка типов» 
(type coercion). Как правило, такие преобразования используются по отноше¬ 
нию к объекту специализированного класса, чтобы присвоить его значение 
объекту более общего класса. Приведение типов не нарушает принцип типи¬ 
зации, поскольку во время компиляции осуществляется необходимый семан- 
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тический контроль. Иногда необходимы операции приведения объектов более 
общего класса к специализированным классам. Эти операции не являются 
надежными с точки зрения строгой типизации, так как во время выполне¬ 
ния программы может возникнуть несоответствие (несовместимость) приводи¬ 
мого объекта с новым типом. Однако такие преобразования достаточно часто 
используются в тех случаях, когда программист хорошо представляет себе 
все типы объектов. Например, в случае невозможности определения пара¬ 
метризованного типа очень часто создаются классы, объединяющие множест¬ 
ва из различных объектов. Чтобы реализовать возможность произвольного 
объединения различных классов в такие множества, вводится понятие едино¬ 
го исходного (базового) класса, такого, как TObject в языке Object Pascal. 
Для итеративных операций, определенных в базовом классе, существенным 
является только способ возврата значения объекта этого класса. На практи¬ 
ке, однако, допускается объединение в общее множество только объектов оп¬ 
ределенных подклассов базового класса TObject. Чтобы выполнить по отно¬ 
шению к объекту специфические операции итеративно, необходимо явно 
привязать объект к ожидаемому типу. При этом также существует опасность 
ошибки исполнения программы, если среди множества объединенных объек¬ 
тов окажется объект недопустимого типа. 

В строго типизированных языках, в отличие от нестрого 
типизированных, методы разрешения неопределенности (поиска функции) 
лучше оптимизировать. В этом случае передача сообщений занимает не 
больше времени, чем вызов обычной подпрограммы. Однако в обеспечении 
параллельности иерархии типов и иерархии наследования есть слабые места. 
В частности, модификация структуры и поведения какого-либо суперкласса 
может повлиять на структуру подклассов. Микаллеф утверждает: «Если пра¬ 
вила типизации основаны на наследовании, то изменения реализации класса, 
затрагивающие его место в иерархической структуре, могут нарушить соот¬ 
ветствие типов класса-пользователя даже при неизменном строении интер¬ 
фейса класса» [35]. Это ставит под вопрос цель механизма наследования. 
Мы уже говорили выше, что цель наследования — разделение ресурсов или 
установление смысловых связей между объектами. Другого подхода 
придерживается Снайдер: «Можно рассматривать наследование как особый 
способ макроопределения кода, что может быть полезным; такой способ 
обеспечивает простоту внесения изменений. С другой стороны, на наследова¬ 
ние можно смотреть как на явное указание логической (смысловой) связи 
порожденного класса с породившим его классом. При этом порожденный 
класс является лишь более специализированным или частично переопреде¬ 
ленным» [36]. В языках Smalltalk, Object Pascal и CLOS объединены оба 
этих подхода. В языке C++ программист имеет более сильные средства ис¬ 
пользования наследования. В частности, если суперкласс данного подкласса 
определен в качестве общедоступного (public), как в примере с классами 
ElectricalData, то это означает, что подкласс одновременно является подти¬ 
пом этого суперкласса (поскольку интерфейс является общим, то структура 
и поведение являются также общими). 

Если же суперкласс объявлен обособленным (private) в описании под¬ 
класса, то подкласс не будет подтипом суперкласса, хотя структура и пове¬ 
дение будут общими. Следовательно, в случае обособленного суперкласса вся 
структура суперкласса становится в подклассе обособленной (private). В этом 
случае два класса (суперкласс и подкласс) не обладают по отношению к 
другим классам одинаковым интерфейсом, что означает отсутствие отноше¬ 
ния тип-подтип. 
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Дадим следующее определение класса: 

class IntemalElectricalData : private ElectricalData { 
public: 

IntemalElectricalData (noat vl,float v2, noat al, float a2); 
IntemalElectricalData (const IntemalElectricalData&); 
virtual -IntemalElectricalData 0; 

ElectricalData :: currentPower; 


В приведенном описании суперкласс ElectricalData объявлен обособлен¬ 
ным, следовательно, методы определенного класса Internal ElectricalData, на¬ 
пример Send, являются закрытыми для всех пользователей. Поскольку класс 
IntemalElectricalData не является подтипом для ElectricalData, мы уже не 
сможем присвоить значения объектов этих классов, как в случае деклариро¬ 
вания суперкласса в качестве общедоступного. Отметим, что функция current 
Power сделана видимой для всех обьектов-пользователей путем явного указа¬ 
ния ее наименования. В другом случае она осталась бы обособленной. Оче¬ 
видно, что в языке C++ невозможно сделать какой-либо элемент подкласса 
более «видимым*, чем такой же элемент суперкласса. Так, элемент id, объ¬ 
явленный в классе Telemetry Data как защищенный, не может быть сделан в 
подклассе общедоступным путем явного наименования (как в случае 
current Power). 

В языке Ada для достижения аналогичного эффекта вместо подтипов 
используется механизм производных типов. Определение подтипа не означа¬ 
ет появление нового типа, а лишь определенное ограничение существующе¬ 
го. Определение производного типа создает самостоятельный новый тип, ко¬ 
торый имеет структуру, заимствованную у исходного типа. В следующем 
разделе показано, что применение отношений наследования в качестве мак¬ 
роопределений и отношений использования вызывает серьезные противоре¬ 
чия. 

Понятие множественного наследования между классами. Мы рассмот¬ 
рели вопросы, связанные с простым наследованием, когда подклассы имеют 
только один исходный суперкласс. Однако, как указали Влисайдес и Линтон: 
«простое наследование при всей своей полезности часто заставляет програм¬ 
миста выбирать между двумя равнопривлекательными классами. Это ограни¬ 
чивает возможность повторного использования переопределенных классов и 
заставляет дублировать уже имеющиеся коды. Например, затруднительно в 
этой ситуации собрать воедино изображение окружности и какой-либо рису¬ 
нок; необходимо выбрать что-то одно и дописать заново структуру класса, 
не вошедшего в наследованный класс» [37]. Множественное наследование 
реализуется в языках C++ и CLOS, а также частично в Smalltalk. Необходи¬ 
мость реализации множественного наследования в OOP остается предметом 
горячих споров. Практика говорит о том, что множественное наследование 
играет роль парашюта: в нем нет постоянной необходимости, но если он 
вдруг понадобился, то большое счастье иметь его под рукой. 

Предположим, что возникла необходимость классифицировать различные 
продукты: бананы, овсяные хлопья, тесто, молоко и говядину. Можно рас¬ 
пределить их по четырем основным группам: овощи и фрукты, мучные про¬ 
дукты, молочные продукты, мясо. Далее отношения устанавливаются путем 
наследования в виде иерархии «по номенклатуре»: молоко — разновидность 
молочных продуктов, которые в свою очередь являются видом пищевых про¬ 
дуктов. 
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Рис. 3-7. Отношения множественного наследования между классами. 

Но есть другие способы классификации продуктов. Например, можно 
классифицировать их по содержанию белков и углеводов. Для такой класси¬ 
фикации простого наследования оказывается недостаточно, и мы приходим к 
понятию множественного наследования. 

На рис. 3-7 показана такая структура классов. Здесь мы видим, что 
овсяные хлопья являются видом мучных продуктов и одновременно источни¬ 
ком углеводов. Говядина является разновидностью мяса и источником бел¬ 
ков. Молоко находится в этой классификации в особом положении: оно от¬ 
носится к числу молочных продуктов и является источником и углеводов, и 
белков. Реализация указанного подхода на языке CLOS состоит в определе¬ 
нии базового класса Food и четырех абстрактных классов, соответствующих 
группам продуктов: 

(defclass food О (...)) 

(defclass fruit-and-vegetable (food) (...)) 

(defclass bread (food) (...)) 

(defclass dairy-product (food) (...)) 

(defclass meat (food) (...)) 

Содержание слотов в определении каждого из классов для краткости 
опущено. Затем определяются классы, соответствующие продуктам питания: 

(defclass high-carbohydrate О (...)) 

(defclass high-prolcin О (...)) 

Наконец, вводятся классы разновидностей продуктов: 
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(defclass banana (fruit-and-vegetable) (...)) 

(defdass bran-flakes (break high-carbohydrate) (...)) 

(defdass pasta (break high-carbohydrate) (...)) 

(defdass milk (dairy-product high-carbohydrate high-protcin) (...)) 

(defdass beef (meat high-protein) (..,)) 

Каждый из этих классов имеет несколько исходных суперклассов. Раз¬ 
работка структуры классов на основе наследования (особенно множественно¬ 
го) — задача достаточно трудная. В гл. 2 мы говорили, что этот процесс 
обычно является ступенчатым и итеративным. При множественном наследо¬ 
вании появляются две дополнительные проблемы: как быть в случае неопре¬ 
деленности в наименовании элементов различных суперклассов и как реали¬ 
зовать повторное наследование. 

Неопределенность наименования имеет место в тех случаях, когда в не¬ 
скольких суперклассах используются одинаковые имена для обозначения эле¬ 
ментов интерфейса (переменных или методов). Предположим, например, что 
в двух классах high-carbohydrate и high-protein имеется слот с именем 
percentage, означающий процент соответственно углеводов и белков в про¬ 
дукте. Поскольку класс milk наследует структуру этих двух классов, то воз¬ 
никает вопрос: а как быть с двумя слотами, имеющими одинаковое имя? 
Эта проблема может быть разрешена тремя основными путями. Во-первых, 
можно запретить при компиляции такой тип наследования. Такой подход 
реализован в языках Smalltalk и Eiffel. Однако в языке Eiffel можно пере¬ 
именовать один из слотов и избежать данной неопределенности. Во-вторых, 
семантика языка может допускать наличие двух одинаковых систем в раз¬ 
ных классах, рассматривая их как один слот; такой подход реализован в 
языке CLOS. В-третьих, можно допускать смешение имен при наличии до¬ 
полнительного квалификатора, указывающего на базовый суперкласс для 
данного имени; так сделано в C++. Вторая проблема связана с повторным 
наследованием и характеризуется Мейером так: «одним из таких мест в свя¬ 
зи с множественным наследованием является проблема неоднократного ис¬ 
пользования одного предка (исходного суперкласса) в каком-либо классе. Ес¬ 
ли множественное наследование допустимо, то рано или поздно кем-то будет 
объявлен класс D, имеющий два суперкласса В и С, которые в свою оче¬ 
редь построены на базе суперкласса А — или каким-либо другим способом, 
когда D дважды (или более) наследует от суперкласса А. Эта ситуация на¬ 
зывается повторным наследованием и требует должного внимания» [38 ]. 
Рассмотрим следующий пример: 

(defdass breakfast-cereal (bran-flakes milk) (...)) 

Данный класс повторно наследует класс high-carbohydrate, являющийся 
суперклассом для bran-flakes и milk. 

Проблема повторного наследования решается тремя способами. Во-пер¬ 
вых, можно запретить наличие повторного наследования. Так сделано в язы¬ 
ках Smalltalk и Eiffel (но в Eiffel допускается переименование для устране¬ 
ния неопределенности). Во-вторых, можно потребовать указания дополни 
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тельного квалификатора, определяющего порядок наследования, как сделано 
в C++. В-третьих, можно трактовать многократное указание на некоторый 
класс как обозначение данного класса. В языке C++ повторное введение су¬ 
перкласса соответствует определению виртуального базового класса. Вирту¬ 
альный базовый класс возникает тогда, когда в некотором подклассе вводит¬ 
ся имя суперкласса с указанием признака виртуальности, что указывает на 
использование ресурсов такого класса. В языке CLOS также используются 
повторные классы на основе списка следования классов. Этот список допол¬ 
няется при введении каждого нового определения класса и учитывает все 
суперклассы для каждого класса, исключая повторения и реализуя следую¬ 
щие правила: 

* Любой класс имеет предшественников в лице его суперклассов. 

* Для каждого класса устанавливается порядок следования его непосредст¬ 
венных суперклассов [39]. 

При этом подходе схема наследования выравнивается, повторения устра¬ 
няются и в результате получается структура, соответствующая простому на¬ 
следованию [40]. Этот процесс можно трактовать как топологическую сорти¬ 
ровку классов. Если общее упорядочение структуры классов реализуется, то 
наличие классов с повторным наследованием допустимо. Следует отметить, 
что процесс упорядочения может быть реализован либо единственным обра¬ 
зом, либо иметь несколько вариантов. Если найти такой порядок не удается 
(например, когда имеются перекрестные и циклические зависимости между 
классами), то описание класса отвергается как ошибочное. В приведенном 
примере класс breakfast-cereal приемлем, поскольку следование суперклассов 
однозначно упорядочено; в иерархию суперклассов класс high-carbohydrate 
входит только один раз. 

Множественное наследование привело к возникновению такой разновид¬ 
ности классов как примеси (Mixins). Этот термин связан с традициями про¬ 
граммирования на языке Flavors: здесь допускается объединять (смешивать) 
более мелкие классы в более сложные. Хендлер утверждает: «Смешение на¬ 
поминает по синтаксису регулярный класс, но имеет совершенно другую 
цель. Цель этого вида классов состоит единственно в ... добавлении функ¬ 
ций по отношению к другим объектам [классам] — экземпляры классов- 
смесей никогда не создаются» [41 ], Классы high-carbohydrate и high-protein 
являются смешиваемыми. Эти классы не нужны сами по себе, а использу¬ 
ются для наполнения других классов особыми свойствами. В языке CLOS 
принято осуществлять смешение за счет квалификаторов: before и after, что¬ 
бы дополнить исходный метод нужными уточнениями. Таким образом, мож¬ 
но определить примесь как некоторый класс, реализующий особый вид пове¬ 
дения, и использовать этот класс для внесения его поведения в другие клас¬ 
сы (через механизм наследования). Как правило, поведение смешиваемого 
класса противоположно поведению классов, с которыми осуществляется сое¬ 
динение. 

Класс, образованный исключительно путем наследования примесей без 
всяких добавлений, называется агрегатироваиным классом. 

Понятие множественного полиморфизма. Определим следующую обоб¬ 
щенную функцию: 

(defgenetic display (rood)) 

8 Гради Буч 



Эта функция предназначена для создания изображения продукта в гра¬ 
фическом окне. В каждом подклассе должен быть описан метод, соответству¬ 
ющий этой обобщенной функции. Таким образом, начинает реализовываться 
механизм полиморфизма — если мы будем реализовывать указанный метод 
по отношению к конкретному объекту, возникнет соответствующее изображе¬ 
ние (сам объект определяет какому классу он принадлежит). Такой поли¬ 
морфизм является простым, поскольку выбор нужного метода осуществляется 
на основе одного параметра. 

Допустим теперь, что нам нужно корректировать поведение метода в 
соответствии с типом используемого дисплейного устройства. В одном случае 
мы будем рисовать изображение с помощью метода display, а в другом пе¬ 
чатать соответствующее текстовое сообщение. Для этого нам придется со¬ 
здать две различные, но очень близкие, обобщенные функции. Такое реше¬ 
ние нельзя считать удовлетворительным, так как описание избыточно. 

Язык CLOS позволяет определить методы, специализированные по не¬ 
скольким параметрам; такие методы называются множественными (multi¬ 
methods). Определим таким образом следующую функцию: 

(genetic display (food display-device)) 

Прежде чем вызывать такую функцию, нужно создать экземпляр одного 
из подклассов food и экземпляр подкласса display-device. Язык CLOS позво¬ 
ляет при вызове такой функции выбрать нужный исходный метод, соответ¬ 
ствующий действительным параметрам. Если найти такой метод не удается, 
то возникает сообщение об ошибке исполнения. Так реализуется множест¬ 
венный полиморфизм. 

Отношения использования 

Пример отношений использования между классами. Не всегда с 
помощью механизма наследования удается адекватно отразить всю совокуп¬ 
ность сложных отношений между абстракциями. Рассмотрим, например, от¬ 
ношения между библиотекой и книгами. Библиотека не является разновид¬ 
ностью книги, а объединяет их. На языке Object Pascal можно дать следую¬ 
щее определение: 

TLibrary - object (TObject) 

procedure TLibrary.Initialize; 

procedure TLibrary.Checkout (ABook : TBook); 

procedure TLibrary.Checkin (ABook : TBook); 

end; 


Часть методов и полей данного класса дЛя краткости опущена. Компи¬ 
ляцию описания этого класса можно осуществить только после компиляции 
класса TBook, поскольку он входит в интерфейс класса TLibrary. Для клас¬ 
са TLibrary использование класса TBook означает, что TLibrary «видим» для 
TBook, а интерфейс и реализация TLibrary могут обращаться к интерфейсу 
(но не к реализации) TBook. Например, реализация метода Checkout подра¬ 
зумевает посылку сообщения объекту ABook, чтобы нужным образом изме¬ 
нить состояние этого объекта (установить метку о прохождении контроля). 
Таким образом, можно видеть, что отношения использования между класса 
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ми похожи, но отличаются от отношений использования между объектами. 
Объекты класса TLibrary (и его подклассов) могут посылать сообщение объ¬ 
ектам класса ТВоок (и его подклассам). 

Понятие отношений использования между классами. Отношения ис¬ 
пользования имеют два различных аспекта: в интерфейсной части одного 
класса может быть использован другой класс (как в предыдущем примере) 
или другой класс используется в реализации. В первом случае используемый 
класс должен находиться в зоне «видимости» классов пользователей. Напри¬ 
мер, код функции, выполняющей контроль книг в библиотеке, должен быта 
«видимым» как для класса TLibrary (здесь происходит вызов функции 
Checkout), так и для ТВоок (чтобы сослаться на объект этого класса). 

Во втором случае используемый класс находится в области ограниченно¬ 
го доступа использующего класса. Например, в реализации класса TLibrary 
может быть употреблен класс TList, представляющий собой список книг. 
Для класса TList необязательно соблюдать требование «видимости» для ин¬ 
терфейса TLibrary, достаточно выполнить условие «видимости» для реализа¬ 
ции TLibrary. Рассмотрим ситуацию, когда любая библиотека может состо¬ 
ять из п книг, но каждая книга имеется только в одной из библиотек. Это 
пример отношения вида 1:п. В другом случае можно допустить, что в каж¬ 
дой библиотеке имеется определенный набор (коллекция) книг и каждая 
коллекция существует только в одной библиотеке. Это пример отношения 
вида 1:1. Возможны и числовые отношения других видов, например m:n. 



Рис. 3-8. Отношения использования между классами. 

Два основных вида отношений использования показаны на рис. 3-8. Об¬ 
ратим внимание на способ отражения разновидностей отношения (использо¬ 
вание класса в интерфейсной части описания или в реализации) и числовых 
отношений. 

В гл. 2 было показано значение ограничения доступа к данным. Однако 
возможны случаи, когда ограничение доступа становится препятствием, осо¬ 
бенно для отношений использования классов. Допустим, что мы создали 
класс TSortedBookList, который используется по отношению к объектам 
ТВоок для осуществления эффективной сортировки. В большинстве языков 
OOP существуют строгие правила защиты информации. В языке C++ реали¬ 
зована возможность ослабить действие таких ограничений путем объявления 
общности (дружественности) классов. Объявление общности (friend) позволя¬ 
ет использовать метод двумя и более объектами разных классов. При этом 
реализация метода для одного из классов может находиться в обособленной 
части класса, который также является дружественным. Другими словами, ус¬ 
тановление отношений общности для структуры и методов класса означает 
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возможность доступа к тем элементам класса, которые в другом случае яв¬ 
ляются обособленными. Как и в обычной жизни, к выбору друга нужно 
подходить осторожно, поскольку такие отношения подразумевает доверие, 
которое применительно к классам означает гарантию неприкосновенности 
данных, оставшихся незащищенными. 

Множественное наследование часто приводит к проблемам в отношениях 
использования. Можно, например, определить класс telephone путем наследо¬ 
вания классов, соответствующих клавиатуре, микрофону и громкоговорителю. 
Можно, наоборот, определить этот же класс путем использования трех ука¬ 
занных классов. В обоих случаях достигается различными путями один и 
тот же эффект. Опыт показывает, что использование множественного насле¬ 
дования для агрегатирования (смысл которого в том, что один объект вклю¬ 
чает несколько других) не эффективно. Телефон не является разновидно¬ 
стью микрофона, а содержит его в себе (использует). Поэтому использова¬ 
ние объектов больше подходит для агрегатирования. Общее правило гласит: 
если некоторая абстракция представляет нечто больше, чем сумму 
некоторых абстракций — пригодны отношения; если абстракция является 
подвидом другой абстракции или соответствует простой сумме компонент, 
следует использовать отношение наследования. 

Отношение наполнения 

Примеры отношений наполнения между классами. В строго типизиро¬ 
ванных языках принято использовать соответствующие особенности проекти¬ 
руемой системы — типы данных. Предположим, что *мы умело пользуемся 
абстракцией универсала с десятью контрольными классами. Для представле¬ 
ния контрольных классов в языках Object Pascal и Ada можно применить 
специфический ограниченный тип целых чисел с диапазоном от 1 до 10. На 
более высоком уровне абстракции нужно образовать множественный класс 
для обозначения группы служащих, произвольно располагаемых по контроль¬ 
ным классам. Здравый смысл подсказывает, что в эту группу будут входить 
только служащие универсама, но не покупатели и уж совсем не овощи. По 
логике нам следует точно определить этот множественный класс (т.е. класс 
входящих в него объектов) и этим гарантировать от попадания в него дру¬ 
гих объектов (средствами языка программирования). 

Множество является примером сборного класса, т.е. класса, экземпляры 
которого состоят из наборов других объектов. Сборные классы могут быть 
однородными (состоять из объектов одного класса) или неоднородными (со¬ 
стоять из объектов разных классов, имеющих общий суперкласс). Наиболее 
часто встречаются такие виды сборных классов, как стек, список, строка, 
очередь, двухсторонняя очередь, замкнутая цепь, маршрут (план), множест¬ 
во, выборка, дерево и граф [42]. 

На языке Ada множественный класс определяется следующим образом: 
generic 

type Item is private; 
package Slmple_Set is 

type Set is limited private; 

procedure Copy (From_The_Set : in Set; 

To_The_Set : in out Set); 

procedure Clear (The_Set : in out Set); 
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Рис. 3-9. Отношения наполнения между классами. 


procedure Add 
procedure Remove 
procedure Union 

procedure Intersection 
procedure Difference 


(Thejtem 
To_The_Set 
(Thejtem 
From_The_Set 
(Of_The_Set 
And_The_Set 
To The_Set 
(Of_The_Set 
AndThe_Set 
To_The_Set 
(Of_The_Set 
And_The_Set 
To_The_Set 


in Item; 

in out Set); 

in Item; 

in out Set); 

in Set; 

in Set; 

in out Set); 

in Set; 

in Set; 

in out Set); 

in Set; 

in Set; 

in out Set); 


(Left 
Right 
(The_Set 
(The_Set 
(Thejtem 
Of The_Set 
(Left 
Right 

function Is_A_Proper_Subset (Left 
Right 

Overflow : exception; 

ItemJsJn_Set : exception; 

Item_Is_NotJn_Set : exception; 


function Is_Equal 

function Expent_Of 
function Is_Empty 
function Is_A_Member 

function Is_A_Subeet 


in Set; 

in Set) return Boolean; 
in Set) return Natural; 
in Set) return Boolean; 
in Item; 

in Set) return Boolean; 
in Set; 

in Set) return Boolean; 
in Set; 

in Set) return Boolean; 


end Slmple_Set; 

Вновь обратим внимание на стиль описания интерфейсной части класса, 
где явно выделены модификаторы и селекторы. Используя этот класс и 
класс Employee, можно осуществить наполнение класса объектами, которые 
принадлежат классу Employee: 

packade Employee_Set is new Simple_Set (Item -> Employee); 

Полагая, что имя множественного объекта Avaiable-Employees, а имена 
служащих, входящих в это множество, Mike, Paul, Dave, Bob и Brett, 
запишем следующие выражения: 

Add (Bob, To_The_Set -> Available JSmployees); 

Add (Paul, To_The_Set -> Available_Employees); 
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Add (Brett, To_The_Set -> Available_Employecs); 

Remove (Mike, From_The_Set -> Available_Employees); 

If I*_A_Member (Dave, Of_The_Sel -> Available_Employees then ... 

Правила строгой типизации языка Ada позволяют отвергнуть все попыт¬ 
ки включить в это множество и выполнить другие операции с объектами 
другого класса (кроме класса, представляющего служащих). 

Значение отношений наполнения между классами. Существует четыре 
основных способа построения сборного класса. Первый способ — использова¬ 
ние макроопределений. Он применяется в C++, но по мнению Страустрапа, 
«этот подход хорош только в небольших проектах* [43], поскольку исполь¬ 
зование макросов неудобно; более того, каждая реализация при этом создает 
новый вариант (версию) кода. Второй способ реализован в языке Smalltalk и 
включает наследование и позднее связывание [44]. По этому методу могут 
создаваться только однородные сборные классы, поскольку каждый элемент 
рассматривается как экземпляр базового класса Object. Третий способ явля¬ 
ется традиционным для языка Object Pascal. Здесь, как и в Smalltalk, созда¬ 
ется обобщенный сборный класс, но затем используется специальная проце¬ 
дура контроля типа, которая позволяет в процессе образования объекта за¬ 
крепить за ним определенный класс элементов. Четвертый способ заключа¬ 
ется в механизме параметризованного класса, впервые реализованном в язы¬ 
ке CLU [45]. Параметризованный класс (называемый также обобщенным 
классом) — это класс, составляющий основание для размещения других 
классов. Он параметризуется классами, объектами и операциями. Параметри¬ 
зованный класс необходимо наполнить (конкретизировать параметры этого 
класса) прежде, чем создавать объекты. Языки Ada и Eiffel реализуют меха¬ 
низм параметризации, а в C++ ожидается появление этого средства в бли¬ 
жайшем будущем. 

Отношения наполнения классов иллюстрируются рис. 3-9. Отметим, что 
для наполнения класса Simple-Set используется класс Employee. Отношения 
наполнения почти всегда сопровождаются отношениями использования, при 
этом происходит выявление действительных классов, наполняющих класс-ос¬ 
нование. 

Мейер доказал, что механизм наследования является более мощным 
средством, чем механизм конкретизации/обобщения, и многие свойства обоб¬ 
щения достигаются путем наследования, но не наоборот [46]. На практике 
всегда полезно иметь дело с языками, реализующими оба механизма — на¬ 
следования и параметризации. 

Параметризованные классы используются не только для построения 
сборных классов. Страустрап утверждает, что «параметризация типов позво¬ 
лит реализовать арифметические функции на основе базового параметра, а в 
конечном счете создать унифицированные функции для любых типов пара¬ 
метров: целых, действительных, двойной точности и т.д.» [47]. С точки зре¬ 
ния поддержки системного проектирования параметризованные классы полез¬ 
ны для описания интерфейсов. При описании операций над объектами мож¬ 
но реализовать подобие шаблона, позволяющего реализовать определенные 
действия над объектами разных классов. Примером может служить абстрак¬ 
ция упорядоченного списка, объекты которого должны сортироваться по не¬ 
которому критерию. Метод, служащий для определения положения объекта в 
списке, может быть параметризован. При этом создается операция, которая 
будет выполняться над элементами списка, представляющими объекты раз¬ 
ных классов. Параметризация класса делает его более свободным (универ- 
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сальным) и, следовательно, пригодным для более широкого использования. 
Класс становится менее специализированным, может конкретизироваться объ¬ 
ектами любых других классов. 

Отношения типа мега класс 

Значение отношений типа метакласс. Три рассмотренных выше типа 
отношений между классами — наследование, использование и наполнение — 
обеспечивают практически все потребности программистов при описании вза¬ 
имоотношений классов. Однако из идеологии объектного подхода вытекает 
еще одна разновидность отношения абстракций. Мы уже говорили, что каж¬ 
дый объект является экземпляром определенного класса (реализацией клас¬ 
са). А если попытаться сделать объектом манипуляций сам класс? Для отве¬ 
та на этот вопрос нужно определить, что такое класс классов. Очевидно, 
что это метакласс. Другими словами, метакласс — это класс, экземпляры 
которого сами являются классами. 

Мотивируя необходимость метаклассов Робсон отмечает, что «при разра¬ 
ботке системы взаимодействие объектов обеспечивается через интерфейс 
классов. По этой причине чрезвычайно полезно обеспечить возможность ма¬ 
нипулирования классами так же, как любыми другими объектами» [48]. Ме¬ 
таклассы в непосредственном виде реализуются в языках CLOS и Smalltalk, 
причем в языке CLOS этот механизм особенно сильно развит. 

В языке Smalltalk метаклассы используются главным образом для ини¬ 
циализации переменных класса и создания одиночных экземпляров мета¬ 
классов [49]. Язык Smalltalk традиционно снабжается рядом примеров, де¬ 
монстрирующих способы применения классов на оснрве метаклассов. 

Примеры использования метаклассов. Предположим, что определен 
класс Timer, объекты которого содержат данные о текущем времени, отсчи¬ 
тываемом в секундах от момента активизации системы. Допускается созда¬ 
ние произвольного числа таких объектов, но каждый из них должен обеспе¬ 
чивать отсчет одного и того же значения времени. Это означает наличие 
общего элемента в описании состояния этих объектов и необходимость пред¬ 
варительной инициализации данного элемента. Как правило, состояние объ¬ 
екта определяется переменными объекта, но можно использовать для этого и 
переменные класса. Переменные класса имеют такой же смысл, как пере¬ 
менные объекта, за исключением того, что их значение является общим для 
всех экземпляров данного класса. Теперь определим на языке Smalltalk 
класс Timer и соответствующий ему метод: 

Object subclass: #Tlmer 
instanceVariableNames: “ 

dassVariableNames: ‘ElapsedSeconds TimesProccss' 
pool Dictionaries: “ 
category: ‘Simulation' 

Times methodsFor: ‘accessing - 
elapsedSeconds 

«Return an Integer value representing the number of seconds that have elapsed since the system was 
activated.» 

^ElapsedSeconds 
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В качестве переменных класса декларированы ElapsedSeconds и 
TimerProcess, следовательно, они будут общими для всех объектов класса 
Timer. Для осуществления инициализации этих двух переменных необходимо 
создать метакласс Timer: 

Times class 

InstanceVariableNames: “ 

Times class methodsFor: ‘initialize-release* 
initialize 

«Reset elapsedSeconds, then start the process to update elapsedSeconds every second.» 

ElapsedSeconds <— 0. 

TimesProcess <— [[(Delay forSecons: 1) wait. 

self elapsedSeconds:self elapsedSeconds + 1. 
true] 

whileTrue] newProcess. 

TimerProcess resume 


«Stop the process to update elapsedSeconds every second.» 

TimerProcess terminate 

Метод initialize называется методом класса. Осуществление этого мето¬ 
да заключается в создании нового процесса (Timer Process), который через 
каждую секунду увеличивает значение переменной elapsedSeconds. 

В языке Smalltalk каждому классу может соответствовать только один 
метакласс (метакласс для класса Timer назван Timer class), но не для всех 
классов в процессе проектирования создаются метаклассы (это определяется 
спецификой предметной области). В приведенном примере прежде всего не¬ 
обходимо инициализировать класс Timer с помощью следующего оператора: 

Timer initialize. 

Поскольку Timer является классом, то процедура initialize должна быть 
определена в его классе, т.е. в метаклассе Timer class. Этот механизм ил¬ 
люстрируется рис. 3-10. 

Что такое класс для метакласса? В языке Smalltalk любой метакласс 
является реализацией класса Metaclass (в том числе и Metaclass class). 
Metaclass является подклассом ClassDescription, который в свою очередь яв¬ 
ляется подклассом Behavior, а последний, наконец, подклассом базового 
класса Object. 

Язык C++ в явном виде не реализует метаклассы, но позволяет созда¬ 
вать переменные класса и методы класса. В частности, можно использовать 
квалификатор static с переменными и функциями класса, чтобы сделать их 
общими для всех экземпляров данного класса. 

Как уже говорилось, в языке CLOS механизм образования метаклассов 
наиболее развит. Здесь метаклассы позволяют переопределять семантику лю¬ 
бых элементов, таких, как старшинство классов, обобщенные функции и ме¬ 
тоды. Основным преимуществом такого мощного механизма является воз¬ 
можность экспериментировать с новыми парадигмами OOP и создавать инст¬ 
рументальные средства программирования с многооконным интерфейсом. 
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Рис. 3-10. Отношения типа метакласс. 

В языке CLOS предопределен класс standard-class, являющийся мета¬ 
классом для всех классов, определенных с помощью квалификатора defclass. 
В этом общем метаклассе определен метод make-instance, определяющий се¬ 
мантику образования экземпляров. Здесь же (в Standard-class) определен ал¬ 
горитм ведения списка старшинства классов. Оба указанных алгоритма в 
языке CLOS можно переопределить. 

В языке CLOS будем рассматривать в качестве объектов метода и обоб¬ 
щенные функции. Поскольку это будут не совсем обычные объекты, введем 
специальный термин «метаобъекты», включающий в себя объекты классы, 
объекты методы и объекты обобщенные функции. Всякий метод является ре¬ 
ализацией предопределенного класса standard-method, а обобщенная функ¬ 
ция — реализацией класса standard-generic-function. В языке CLOS допуска¬ 
ется переопределение всех методов в предопределенных классах, а следова¬ 
тельно, можно изменить поведение всех методов и обобщенных функций. 

3.5. ВЗАИМОСВЯЗЬ КЛАССОВ И ОБЪЕКТОВ 
Отношения между классами и объектами 

Классы и объекты — тесно связанные понятия. В частности, каждый 
объект является экземпляром какого-либо класса, а класс может порождать 
любое число объектов. В большинстве практических случаев классы статич¬ 
ны, т.е. все их особенности и содержание определены в процессе компиля¬ 
ции программы. Из этого следует, что любой созданный объект относится к 
строго фиксированному классу. Объекты, наоборот, в процессе выполнения 
программы непрерывно создаются и разрушаются. 

В качестве примера рассмотрим классы и объекты для задачи 
управления воздушным движением. Наиболее важные абстракции в этой за¬ 
даче — самолеты, графики полетов, маршруты, воздушное пространство и 
его распределение. Эти классы объектов по смыслу достаточно статичны. Та¬ 
кая статичность необходима, иначе невозможно решить задачу перелета из 
одного места в другое так, чтобы два самолета не оказались одновременно в 
одной точке пространства. 
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Объекты этих классов, наоборот, весьма изменчивы и динамичны. Но¬ 
вые маршруты полетов возникают не так часто. Существенно быстрее изме¬ 
няются типы самолетов, находившихся в эксплуатации. Быстрота, с которой 
самолеты занимают и покидают воздушные коридоры, имеет еще большую 
динамику. 

Роль классов и объектов в процессе проектирования 
На этапе анализа и ранних стадиях проектирования решаются две 
основные задачи: 

* Выявление классов и объектов, составляющих словарь предметной области. 

* Построение структур, обеспечивающих совместное взаимодействие объек¬ 
тов, при котором достигаются заданные требования. 

В первом случае говорят о ключевых абстракциях задачи (совокупность 
классов и объектов), во втором — о механизмах реализации (совокупность 
структур). В первой фазе проекта внимание проектировщика сосредоточива¬ 
ется на внешних проявлениях ключевых абстракций и механизмов. Такой 
подход создает логический каркас системы, состоящий из структуры классов 
и структуры объектов. На последующих фазах проекта, включая реализа¬ 
цию, внимание переключается на внутреннее поведение ключевых абстрак¬ 
ций и механизмов и охватывает вопросы их физического представления. 
Принимаемые в процессе проектирования решения составляют архитектуру 
модулей системы и архитектуру процессов в системе. 

3.6. ВОПРОСЫ КАЧЕСТВА ПРИ СОЗДАНИИ КЛАССОВ 
И ОБЪЕКТОВ 

Определение качества абстракций 

По мнению Ингалса: «Для построения системы должен использоваться 
минимальный набор неизменяемых компонент; сами компоненты должны 
быть по возможности стандартизованы и связаны единым способом построе¬ 
ния» [50]. Применительно к OOD такими компонентами являются классы и 
объекты, отражающие ключевые абстракции системы, а единство построения 
(каркас) обеспечивается соответствующими механизмами реализации. 

Опыт показывает, что процесс выделения классов и объектов является 
последовательно-итеративным. В действительности, за исключением самых 
простых задач, с первого раза не удается окончательно выделить и описать 
классы. В гл. 4 и 7 показано, как в процессе работы происходит сглажива¬ 
ние противоречий, возникающих при начальном определении абстракций. 
Очевидно, такой процесс связан с дополнительными затратами на переком¬ 
пиляцию, согласование и внесение изменений в проект системы. Очень важ¬ 
но, следовательно, с самого начала по возможности приблизиться к правиль¬ 
ным решениям, чтобы сократить число последующих шагов приближения к 
истине. Для оценки качества классов и объектов, выделяемых в системе, 
можно предложить следующие пять критериев: 

* Взаимозависимость 

* Связность 

* Достаточность 

* Полнота 

* Простота (безызбыточность) 
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Термин «взаимозависимость» (coupling) заимствован из структурного 
проектирования, но в более вольном толковании он используется и в OOD. 
Стивенс, Майерс и Константин определяют его так: «степень глубины связей 
между отдельными модулями. Фрагменты системы, сильно зависимые от 
других, гораздо сложнее воспринимать, заменять и модифицировать. Для 
улучшения качества системы следует по возможности избегать сильной зави¬ 
симости между отдельными модулями» [51]. Пример правильного подхода к 
проблеме взаимозависимости приведен Пэйдж-Джонсом в виде модульной 
стереосистемы, где усилитель мощности размещен в конструкции колонки 
громкоговорителей [52 ]. 

Кроме взаимозависимости модулей в OOD существенным фактором яв¬ 
ляется зависимость между классами и объектами. Существует определенное 
противоречие между явлениями зависимости и наследования. С одной сторо¬ 
ны, желательно избегать сильной взаимозависимости классов; с другой сто¬ 
роны, механизм наследования — тесно связывающий подклассы с суперклас¬ 
сами — помогает выгодно использовать сходство абстракций. 

Понятие связности также заимствовано из структурного проектирования. 
Связность — это степень взаимодействия между элементами отдельного мо¬ 
дуля (а для OOD еще и отдельного класса или объекта). Наименее жела¬ 
тельной является связность по случайному принципу, когда в одном классе 
или модуле собираются совершенно независимые абстракции. Для примера 
можно вообразить класс, соединяющий абстракции собак и космических ап¬ 
паратов. Наиболее желательной является функциональная связность, при ко¬ 
торой все элементы класса или модуля тесно взаимодействуют в достижении 
определенной цели. Так, например, класс «собака» будет функционально 
связанным, если он описывает поведение собаки, собаки в целом и ничего, 
кроме собаки. 

К идеям взаимозависимости и связности тесно примыкают понятия до¬ 
статочности, полноты и простоты. Под достаточностью подразумевается 
наличие в классе или модуле программы всего необходимого для реализации 
логичного и эффективного поведения. Иначе говоря, компоненты должны 
быть полностью пригодны к использованию. Для примера рассмотрим класс 
«множество». Операция удаления элемента из множества в этом классе, оче¬ 
видно, необходима, но будет ошибкой не включить в этот класс и операцию 
добавления элемента. Нарушение требования достаточности обнаруживается 
очень быстро, как только создается класс-пользователь такой абстракции. 
Под полнотой подразумевается наличие в интерфейсной части класса всех 
необходимых характеристик абстракции. Идея достаточности предъявляет к 
интерфейсу минимальные требования, а идея полноты охватывает все суще¬ 
ственные аспекты абстракции. Полнотой характеризуется такой класс или 
модуль, интерфейс которого гарантирует все необходимое для взаимодействия 
с пользователями. Полнота является субъективным фактором, и разработчи¬ 
ки часто ей злоупотребляют, вынося на верхний уровень такие операции, 
которые можно реализовать на более низком уровне. Из этого вытекает тре¬ 
бование простоты (минимальной необходимости). Простыми являются только 
такие операции, которые обеспечивают реализацию эффективного действия 
абстракции. Так, в примере с «множеством» операция добавления элемента 
является примитивной, а операция добавления четырех элементов не будет 
примитивной, так как эффективно реализуется через операцию добавление 
одного элемента. Конечно, эффективность тоже субъективный фактор. Опе¬ 
рации прямого доступа к структуре данных являются примитивными по оп- 
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ределению. Операции, которые можно свести к нескольким примитивным, но 
при этом затрачиваются значительные вычислительные ресурсы, также явля¬ 
ются потенциально кандидатами на включение в разряд примитивных. 

Эвристический подход к выбору операций 

Функциональная семантика. Реализация интерфейса класса или модуля 
является сложной задачей. Обычно вначале делается первое приближение по 
структуре класса, а затем выявляются требования по уточнению, модифика¬ 
ции и дополнению, обеспечивающие связь с пользователями этого класса. В 
частности может возникнуть потребность в создании новых классов или в 
изменении взаимодействия между существующими. 

В пределах каждого класса принято иметь только простые (примитив¬ 
ные) операции, отражающие отдельные аспекты поведения. Такие методы 
называются тонко-структурированными. Принято также отделять методы, не 
связанные между собой. Это облегчает образование подклассов с переопреде¬ 
лением логики поведения. Решение о количестве определяемых методов мо¬ 
жет быть обусловлено двумя причинами: описание поведения в одном мето¬ 
де упрощает интерфейс, но усложняет и увеличивает размеры самого мето¬ 
да; расщепление метода усложняет интерфейс, но делает каждый из методов 
проще. По наблюдению Мейера «хороший проектировщик умеет найти 
компромисс между большим числом связей из-за дробления системы на 
фрагменты и большим размером модулей, еще поддающихся управле¬ 
нию* [53]. 

В OOD принято создавать методы для класса как целого, поскольку эти 
методы неразрывны в процессе реализации внутреннего протокола абстрак¬ 
ции. Таким образом, определив характер поведения, нужно решить в каком 
из классов это поведение реализуется. Хальберд и О’Брайен предложили 
следующие критерии для принятия такого решения: 


* «Повторяемость 

* Сложность 

* Применимость 

* Знание реализации 


Будет ли это поведение реализовано в несколь¬ 
ких вариантах? 

Как трудно реализовать такое поведение? 
Насколько данное поведение характерно для 
конкретного класса? 

Зависит ли реализация данного поведения от 
особенностей структуры класса?» [54] 


Обычно операции декларируются в том классе, к объектам которого от¬ 
носятся данные действия. Однако в языках Object Pascal, C++, CLOS и Ada 
допускается описание операции в виде общедоступных подпрограмм, группи¬ 
руемых в утилиты класса. Общедоступная подпрограмма по терминологии 
C++ — это функция, не являющаяся элементом класса. Общедоступные под¬ 
программы не могут переопределяться как обычные методы и остаются неиз¬ 
менными. Наличие утилит класса позволяет выполнить требование простоты 
(примитивности) и уменьшить взаимосвязанность классов, особенно операций 
высокого уровня над объектами различных классов. 

Распределение памяти и времени. После того как мы определились с 
функциональными вопросами, следует принять решение о распределении 
Времени и памяти, которое соответствует выполненным действиям. Для вы¬ 
ражения таких решений принято используовать понятие лучшего, среднего и 
худшего вариантов, где худший — это нижний допустимый предел. К 
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данной проблеме тесно примыкает вопрос синхронизации, хотя для большин¬ 
ства языков программирования синхронизация просто не реализуется из-за 
одноканального управления (последовательности объектов). 

В таком случае говорят о передаче сообщений, так как их семантика 
сходна с обычным вызовом подпрограмм. В языках, реализующих параллель¬ 
ность (таких как Ada), передача сообщений уже не является простым про¬ 
цессом, поскольку нужно решать вопросы неопределенности управления объ¬ 
ектом по двум независимым каналам. Объекты, защищенные от такой неоп¬ 
ределенности, являются либо заблокированными, либо параллельными (в за¬ 
висимости от активизации самого объекта). 

Для отражения параллельности отдельных операций и объекта в целом 
используются специальные семантические приемы. В соответствии с ними 
выделяют следующие формы передачи сообщений: 


* Синхронная 


* Отсроченная 


* Задержанная 

* Асинхронная 


Операция активизируется только по готовности пере¬ 
дающего и принимающего сообщения; ожидание вза¬ 
имной готовности может быть неопределенно долгим 
Соответствует в основном синхронной, но в случае 
неготовности принимающего передающий не выполня¬ 
ет операцию 

Вид синхронной с оговоренным временем ожидания 
готовности принимающего 

Посылающий сообщение выполняет операцию вне за¬ 
висимости от готовности принимающего 


Нужная форма выбирается для каждой операции только после принятия 
функциональных решений. 

Эвристический подход к определению взаимоотношений 

Критерии оценки взаимоотношений. Отношения между классами и объ¬ 
ектами связаны с конкретными действиями. Если мы хотим, чтобы объект X 
послал объекту Y сообщение М, то прямо или косвенно класс X должен 
быть доступен («видим») для класса Y, иначе невозможно определить в 
классе X операцию М. Объект X также должен быть «видим» для Y, иначе 
Y не будет знать о существовании X. Под доступностью и видимостью по¬ 
нимается способность одной абстракции обращаться к внешним ресурсам 
другой абстракции. Таким образом, взаимозависимость является мерой види- 


Одним из полезных правил является закон Деметера, который устано¬ 
вил, что «методы любого класса не должны зависеть от структуры других 
классов, за исключением собственной структуры (верхнего уровня). В каж¬ 
дом методе посылаются сообщения только объектам из предельно ограни¬ 
ченного множества классов» [55]. Следование этому закону позволяет созда¬ 
вать близко связанные классы, реализация которых защищена от доступа. 
Такие классы достаточно автономны и для понимания их логики нет необ¬ 
ходимости знать строение других классов. При анализе структуры классов 
для системы в целом можно обнаружить, что иерархия наследования либо 
широкая и мелкая, либо узкая и глубокая, либо сбалансированная. 

В первом случае структура классов выглядит как лес из свободно сто¬ 
ящих классов, которые могут свободно смешиваться и вступать во взаимоот- 
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ношения [56]. Во втором случае структура классов напоминает одно дерево 
из ветвей-классов, имеющих общего предка [57 ]. Каждый из вариантов име¬ 
ет свои достоинства и недостатки. Между отдельными классами существует 
более тесная взаимозависимость, но совсем не используется общность струк¬ 
туры. В случае дерева классов эта общность используется максимально, поэ¬ 
тому каждый из классов имеет меньший размер. 

Однако для понимания сущности таких классов нужно знать все осо¬ 
бенности наследованных или использованных свойств других классов. Иногда 
требуется выбирать между отношениями наследования и использования. На¬ 
пример, следует ли в классе «автомобиль» использовать или наследовать 
классы «двигатель» и «колесо»? В данном случае более целесообразны отно¬ 
шения использования. По мнению Мейера, между классами А и В «отноше¬ 
ния наследования более пригодны тогда, когда любой объект класса В мо¬ 
жет рассматриваться одновременно как объект А» [58]. Если же объект яв¬ 
ляется больше, чем сумма отдельных частей, то более целесообразны отно¬ 
шения использования. 

Роль механизмов реализации и «видимости». Отношения между объек¬ 
тами определяют в основном и механизмы их взаимодействия. Вопрос состо¬ 
ит только в направлении реализации определенных действий. Например, на 
ткацкой фабрике материалы (партии) поступают на участки для обработки. 
На каждом участке можно заменить управляющего. Является ли поступле¬ 
ние материала на участок операцией над помещением, над материалом или 
тем и другим сразу? Если это операции над помещением, то помещение 
должно быть «видимо» для партии материала. Если это операция над мате¬ 
риалом, то материал должен быть «видим» для помещения, так как партия 
материала должна различать помещения участков. В последнем варианте 
(операция над помещением и материалом) нужно обеспечить взаимную «ви¬ 
димость». 

Теперь следует определить отношение между управляющим участком и 
помещением (но не материалом и управляющим); либо управляющий дол¬ 
жен знать о помещении, либо помещение об управляющем. Иногда в про¬ 
цессе проектирования полезно определить в явном виде «видимость» объек¬ 
тов. Существуют три основных способа реализации видимости объекта X 
объекту Y: 

* Размещение в одной Y находится в зоне видимости X; поэтому X 

может прямо именовать Y 

* Использование Y передается в качестве параметра какой-либо 

операции над X 

* Использование поля Y является полем объекта X 

Эти способы являются вариациями идеи общей зоны «видимости». Y 
может быть полем X и при этом находится в зоне видимости других объек¬ 
тов. В языке Smalltalk такой способ означает зависимость двух объектов. 
Общая зона видимости приводит к общности структуры, т.е. общая часть 
структуры доступна по нескольким направлениям. Такие отношения не всег¬ 
да желательны, поэтому целесообразно пользоваться их явным указанием в 
процессе проектирования. 
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Эвристический подход к реализации выбора 

Внутреннее строение (реализация) классов и объектов разрабатывается 
только после завершения проектирования их внешнего облика. При этом не¬ 
обходимо принять два проектных решения: выбрать способ представления 
класса или объекта и способ размещения их в модуле. 

Представление классов и объектов. Представление классов и объектов 
почти всегда связано с ограничением доступа к элементам абстракции. Это 
позволяет вносить изменения (например, перераспределение памяти и вре¬ 
менных ресурсов) без нарушения функциональных связей с другими класса¬ 
ми и объектами. Вирт считает, что «выбор способа представления является 
нелегкой задачей и не определяется только техническими возможностями. 
Он всегда должен рассматриваться с точки зрения операций над данны¬ 
ми» [59]. Рассмотрим, например, класс, соответствующий совокупности пла¬ 
нов полета самолетов. Как его нужно оптимизировать — по эффективности 
поиска или по времени включения в план и удаления из него? Поскольку 
невозможно реализовать и то и другое одновременно, нужно сделать выбор 
на основе знаний и.характера задачи. Не всегда удается сделать такой вы¬ 
бор и тогда создается семейство классов с одинаковым интерфейсом, поведе¬ 
ние которых зависит от направления оптимизации. 

Одним из наиболее трудных решений является выбор между возможно¬ 
стью вычисления элементов состояния объекта и их хранением в виде поля 
данных. Рассмотрим, например, класс «корпус» с соответствующим ему ме¬ 
тодом «объем». Этот метод возвращает значение объема объекта. В структу¬ 
ре объекта хранятся данные о высоте конуса и радиусе основания в виде 
отдельных полей. Следует ли еще создать поле данных для значения объема 
или следует вычислять его по мере необходимости с помощью метода «объ¬ 
ем» [60]? Если мы хотим получать значение объема максимально быстро, 
нужно создавать соответствующее поле данных. Если важнее экономия па¬ 
мяти, лучше вычислить это значение. Оптимальный способ представления 
объекта всегда определяется характером решаемой задачи., В любом случае 
этот выбор не должен зависеть от внешних особенностей (интерфейса) клас¬ 
са, наоборот, такой выбор нс должен сказываться на отношениях с объекта- 
ми-пользователями. 

Размещение классов и объектов в модуле программы. Аналогичный 
вопрос возникает при выборе места для декларирования классов и объектов 
в программном модуле. В языке Smalltalk эта проблема отсутствует, здесь 
модульный механизм не реализуется. В языках Object Pascal, C++, CLOS и 
Ada существует понятие модуля как отдельной языковой конструкции. Ре¬ 
шение о месте декларирования классов и объектов в этих языках является 
компромиссом требований «видимости» и защиты информации. В общем слу¬ 
чае модули должны быть функционально связанными и зависимыми. При 
этом следует учитывать ряд нстехничсских факторов, таких, как повторное 
использование, документирование, требования секретности. Проектирование 
модулей — не менее простой процесс, чем проектирование классов и объ¬ 
ектов. О проблеме защиты информации Парнас, Клементс и Вейс говорят 
следующее: «Реализация этого принципа не всегда является очевидной. Не¬ 
обходимо минимизировать стоимость программных средств (в целом за время 
эксплуатации) и оценить вероятность внесения изменений. Такая оценка ис¬ 
ходит из практического опыта и знания предметной области, включая тех¬ 
нологию программирования и аппаратную реализацию» [61 ]. 
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Заключение 

* Объект характеризуется состоянием, поведением и индивидуальностью. 

* Структура и поведение схожих объектов описывается в общем для них 
классе. 

* Состояние объекта охватывает все его свойства (обычно статические) и их 
текущие значения (динамические). 

* Поведение объекта характеризует изменение его состояния в процессе вза¬ 
имодействия с другими объектами и формируемые при этом сообщения. 

* Индивидуальность объекта — это свойство, отличающее его от всех дру¬ 
гих объектов. 

* Иерархия объектов может строиться на принципах использования или 
включения. 

* Множество объектов с одинаковой структурой и поведением является клас¬ 
сом. 

* Иерархия классов может строиться на принципах наследования, использо¬ 
вания, наполнения (конкретизации) и включать метаклассы. 

* Классы и объекты, образующие словарь предметной области, называются 
ключевыми абстракциями. 

* Структура, объединяющая множество объектов и обеспечивающая их со¬ 
вместное, целенаправленное функционирование, называется механизмом 
реализации. 

* Качество абстракций может быть оценено критериями взаимозависимости, 
связанности, достаточности, полноты и простоты. 

Дополнительная литература 

MacLennan [G, 1982] рассматривает различия между значениями и объ¬ 
ектами. В работе Meyer [J, 1987] вводится идея программирования в виде 
взаимодействия. Статьи Albano [G, 1983], Brachman [J, 1983], Hailpern и 
Nguyen [G, 1987], Wegner и Zdonik [J, 1988] составляют прекрасный теоре¬ 
тический фундамент по всем вопросам данной главы. Cook и Palsberg 
[J, 1989] дали формальное описание наследования. Wirth [I, 1987] предло¬ 
жил расширение для типа «запись» в языке ОЬегоп. 

Ingalls [G, 1986] подробно рассматривает множественный полиморфизм. 
Практическое руководство по эффективному использованию механизма на¬ 
следования предложено Meyer [G, 1988], Halberg и O’Brien [G, 1988]. 
LaLonde и Pugh [J, 1985] разработали подходы к обучению использования 
обобщения и специализации. 

Meyer [G, 1986] рассмотрел вопросы обобщения и наследования приме¬ 
нительно к языку Eiffel. Stroustrup [G, 1988] предложил механизм парамет¬ 
ризации типов в C++. 

Альтернативный подход к иерархии классов реализуется с помощью ме¬ 
ханизма делегирования экземплярами. Подробно этот механизм описан Stein 
[G, 1987]. 




Глава 4 


Классификация 

Классификация — средство упорядочения знаний. В объектно-ориентиро¬ 
ванном анализе определение общих свойств объектов помогает найти общие 
ключевые абстракции и механизмы, что в свою очередь приводит к более 
простому проекту системы. К сожалению, пока не разработаны строгие ме¬ 
тоды классификации и нет правила, позволяющего выделять классы и объ¬ 
екты. Нет таких понятий, как «совершенная структура классов», «правиль¬ 
ный выбор объектов». Как и во многих технических дисциплинах, выбор 
классов является компромиссным решением. На одной из конференций про¬ 
граммистам был задан вопрос: «Какими правилами вы руководствуетесь при 
определении классов и объектов?» Страустрап, разработчик языка C++, отве¬ 
тил шуткой: «Мне помогает святой Грааль». Габриель, один из разработчи¬ 
ков CLOS, ответил: «Это вопрос, на который нет простого ответа. Я просто 
пробую» [1 ]. К счастью, имеется богатый опыт классификации в других об¬ 
ластях науки, на основе которого разработаны методики объектно-ориентиро¬ 
ванного анализа и прикладного анализа. Каждая такая методика предлагает 
свои правила идентификации классов и объектов. 

4.1. ВАЖНОСТЬ ПРАВИЛЬНОЙ КЛАССИФИКАЦИИ 
Классификация и объектно-ориентированное проектирование 

Определение классов и объектов — одна из самых сложных задач 
объектно-ориентированного проектирования. Успешному решению этой задачи 
обычно сопутствуют открытия и изобретения. С помощью открытий мы рас¬ 
познаем ключевые понятия и механизмы, которые образуют "словарь" про¬ 
блемы. С помощью изобретений мы конструируем обобщенные понятия, а 
также новые механизмы, которые определяют правила взаимодействия объ¬ 
ектов. Поэтому открытия и изобретения являются неотъемлемой частью ус¬ 
пешной классификации. Целью классификации является нахождение общих 
свойств объектов. Классифицируя, мы объединяем в одну группу объекты, 
имеющие одинаковое строение или одинаковое поведение. Разумная класси¬ 
фикация, несомненно, часть любой точной науки. Михальский и Стер ут¬ 
верждают, что «неотъемлемой задачей науки является построение содержа¬ 
тельной классификации наблюдаемых объектов и ситуаций. Такая классифи¬ 
кация существенно облегчает понимание основной проблемы и дальнейшее 
развитие научной теории» [2]. Неудивительно, что классификация затраги¬ 
вает многие аспекты объектно-ориентированного проектирования. Она помо¬ 
гает определить обобщенную, специализированную и- собирательную иерар¬ 
хии классов. Определив общие формы взаимодействия объектов, мы найдем 
механизм, который может стать стержнем реализации проекта. Классифика¬ 
ция помогает правильно определять модульную структуру. Мы можем распо¬ 
ложить объекты в одном или разных модулях - это зависит от степени об¬ 
щности объектов; взаимосвязь и влияние — всего лишь меры этой общно¬ 
сти. Классификация играет также роль при распределении процессов между 
процессорами, направляя процессы в один процессор или в разные процессо¬ 
ры в зависимости от того, как эти процессы связаны друг с другом. 

9 Гради Буч 



Классификация упорядочивает знания. 

Трудности классификации 

Примеры классификаций. В гл. 3 мы определили «объект» как нечто, 
имеющее четкие границы. На самом деле ото нс совсем так. Границы пред¬ 
метов часто очень нечеткие. Например, посмотрите на вашу ногу. Попытай¬ 
тесь определить, где начинается и кончается колено. На примере разговор¬ 
ной речи трудно понять, почему некоюрым образом соединенные звуки оп¬ 
ределяют целое слово, а нс часть како"о-то еще большего слова. И если мы 
проектируем некоторую аудиосистему, стоит ли определять класс как состо¬ 
ящий из звуков или состоящий из слои? Как понимать отдельные фразы, 
предложения, параграфы, документы? 

То, что разумная классификация — трудная проблема — факт, извест¬ 
ный давно. И поскольку следует ожидать такие же трудности в объектно- 
ориентированном проектировании, рассмотрим примеры классификации в 
биологии и химии. Вплоть до 18 в. идея о возможности классификации жи¬ 
вых организмов по степени сложности была господствующей. Мера сложно¬ 
сти была субъективной, поэтому неудивительно, что человек оказался в спи¬ 
ске на первом месте. В середине І7 в. шведский ботаник Карл Линней 
предложил более подробную таксономию для классификации организмов: он 
ввел понятия рода и вида. Век спустя Дарвин выдвинул теорию, по которой 
механизмом эволюции является естественный отбор и ныне существующие 
виды животных — продукт эволюции древних животных. Теория Дарвина 
основывалась на разумной классификации видов. Как утверждает Дарвин, 
«натуралисты пытаются расположить виды, роды, семейства в каждом классе 
с помощью натуральной системы отбора. Что подразумевается под этой сис¬ 
темой? Некоторые авторы понимают некоторую простую схему, позволяю 
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щую расположить наиболее похожие живые организмы в один класс и раз¬ 
личные — в разные классы» |3|. В современной биологии термин «класси¬ 
фикация» обозначает «установление иерархической системы категорий на ос¬ 
нове некоторых предопределенных связей между организмами* [4 ]. Наиболее 
общее понятие в биологической таксономии — мир, затем в порядке убыва¬ 
ния общности тип, класс, подтип, сорт, семейство, род и, наконец, вид. Ис¬ 
торически сложилось, что место каждого организма в иерархической системе 
определяется на основании внешнего и внутреннего строения тела и эволю¬ 
ционных связей. В современной классификации живых организмов определя¬ 
ются группы организмов, имеющих общее генетическое наследство, т.е. орга¬ 
низмы, имеющие общие DNA, включаются в одну группу. 

Возможно, для программиста-матсматика биология представляется зре¬ 
лой, вполне сформировавшейся наукой с определенными критериями класси¬ 
фикации организмов. Но это не так. По словам биолога Мэя: «На сегод¬ 
няшний день мы даже не знаем порядок числа видов растений и животных, 
населяющих нашу планету: классифицировано менее чем 2 млн. видов, в то 
время как возможное число видов оценивается от 5 до 50 млн.». [51 Болес 
того, различные критерии классификации одних и тех же организмов приво¬ 
дят к разным результатам. Мартин утверждает, что «все зависит от того, 
что вы хотите получить. Если вы хотите, чтобы классификация отражала 
генетическое родство видов, вы получите один ответ, если вы желаете полу¬ 
чить информацию об адаптационных свойствах организмов — ответ будет 
другой» [6]. Можно заключить, что даже в строгих научных дисциплинах 
методы и критерии классификации сильно зависят от результата, который 
вы хотите достичь. 

Аналогичная ситуация сложилас» и в химии |7 ]. В древние времена 
считалось, что все вещества — суть комбинации земли, воздуха, огня и во¬ 
ды. В настоящее время такая классификация не может считаться сколько- 
нибудь удовлетворительной. В середине 1600-х годов химик Роберт Бойль 
предположил существование элементов как неких примитивных элементов, 
из которых составляются более сложные вещества. Век спустя химик Лаву¬ 
азье опубликовал первый список, содержащий 23 элемента, хотя впоследст¬ 
вии было открыто, что некоторые из них не являются элементами. Но от¬ 
крытие новых элементов продолжалось, список увеличивался. Наконец, Мен¬ 
делеев предложил периодический закон, который давал точные критерии для 
классификации известных элементов и даже мог предсказывать свойства еще 
нс открытых элементов. Но даже это открытие не оказалось окончательным 
решением задачи классификации элементов. В 1900-е годы были открыты 
элементы с одинаковыми химическими свойствами, но с разной атомной 
массой — изотопы. Как утверждал Декарт: «Открытие какого-либо порядка 
вешей не просто, но если он найден, нет никаких трудностей в его понима¬ 
нии» [8 1. 

Методы классификации. Все это мы привели здесь нс для того, чтобы 
оправдать длительность разработки программного обеспечения, хотя на самом 
деле многим менеджерам и пользователям кажется, что необходимы века, 
чтобы закончить начатую работу. Мы просто хотели подчеркнуть, что ра¬ 
зумная классификация — работа интеллектуальная и лучший способ ее ве¬ 
дения — последовательный итеративный процесс. Это становится очевидно 
при анализе процесса разработки такгх программных продуктов, как графи¬ 
ческий интерфейс, база данных и языки программирования четвертого поко¬ 
ления. Шоу утверждает, что «развитие какой-либо абстракции часто следует 
общему рисунку. В начале проблема решается аіі іюс. По мерс накопления 



опыта некоторые решения оказываются более удачными, чем другие, разви¬ 
вается некоторый фольклор по данной теме. Удачные решения изучаются 
более систематично. Это позволяет разнить модель, которая помогает опреде¬ 
лить способ реализации и разработать теорию, обобщающую это решение, 
что в свою очередь повышает уровень всей разработки и позволяет взяться 
за еще более сложную задачу, к которой в свою очередь мы подходим ad 
hoc, тем самым замыкая круп» [9|. 

Последовательный итеративный подход непосредственно определяет про¬ 
цедуру конструирования иерархии классов и объектов при разработке слож¬ 
ного программного обеспечения. На практике обычно за основу берется ка¬ 
кая-то определенная структура классог, которую постепенно совершенствуют. 
И только на поздней стадии разработки, когда уже получен некоторый опыт 
использования такой структуры, мы можем критически оценить качество по¬ 
лучившейся классификации. Основываясь на полученном опыте, мы можем 
создать новые подклассы из уже существующих или слить несколько суще¬ 
ствующих в один (декомпозиция). Возможно, в процессе разработки были 
найдены новые общие свойства, ранее нс замеченные, и мы можем опреде¬ 
лить новые классы (abstraction) [10]. 

Почему же классификация так сложна? Мы объясняем это двумя важ¬ 
ными причинами. Во-первых, потому, что нет определения «совершенная» 
классификация, хотя естественно некоторые лучше других. Комбс, Рафиа и 
Фарол утверждают, что «существует столько способов деления мира на объ¬ 
ектные системы, сколько ученых принимается за эту задачу: способ класси¬ 
фикации определяется целью, к которой мы стремимся на этом пути» [11]. 
Флуд и Каркон приводят пример: «Соединенное Королевство экономисты мо¬ 
гут рассматривать как экономическую систему, социологи — как социальное 
общество, правительство СССР — как военную угрозу и т.д.». [12] Во-вто¬ 
рых, разумная классификация требует большой творческой энергии и прони¬ 
цательности. Биртвисл, Дсйх и Майтл заключают, что «иногда ответ очеви¬ 
ден, иногда он зависит от вкуса, а бывает, что выбор подходящих компо¬ 
нентов структуры очень критичен» 1131. Все это напоминает загадку — 
«Почему лазерный луч похож на золотую рыбку?..., потому что ни тот, ни 
другой нс свистят» 114 ]. Только творческий разум может найти общее в 
столь разных и несвязанных предметах. 

4.2. ИДЕНТИФИКАЦИЯ КЛАССОВ И ОБЪЕКТОВ 
Классический и современный подходы 

Еще со времен Платона проблема классификации занимала умы раз¬ 
личных философов, лингвистов, когнитивистов, математиков. Поэтому было 
бы разумно изучить накопленный опыт и применить его по возможности в 
объектно-ориентированном проектировании. Исторически сложились только 
три основных подхода классификации: 

* Классическое распределение по категориям. 

* Концептуальное объединение. 

* Теория прототипов |15|. 

Классическое распределение по категориям. В классическом подходе 
распределения по категориям: «все веши, обладающие данным свойством или 
совокупностью свойств, формируют некоторую категорию. Причем наличие 
этих свойств является необходимым и достаточным условием, определяющим 
категорию» [16]. Например, холостые люди определяют категорию: каждый 




человек или холост, или женат этот признак достаточен дли решения воп¬ 
роса, к какой группе принадлежит тот'или иной индивидуум. С другой сто¬ 
роны, высокие люди нс определяют категории, если, конечно, мы специаль¬ 
но не уточним критерий, позволяющий четко различать высоких людей от 
невысоких. Впервые классическое распределение по категориям упоминается 
Платоном. В том виде, в котором им пользовался Аристотель, оно напоми¬ 
нает современную детскую игру в «двадцать вопросов» (это минерал, живо¬ 
тное или растение? Это имеет мех или перья? Может ли оно летать?) [17 J. 
Такой подход нашел последователей; наиболее выдающиеся из них: Акуинас, 
Декарт, Лок. По утверждению Акуинаса: «Мы именуем вещь согласно на¬ 
шим знаниям об их свойствах» 118 |. 

Принципы классического распределения по категориям четко проявляют¬ 
ся в современной теории развития детей. Пайджст утверждает, что после 
первого года жизни ребенок осознает постоянство объектов и затем начинает 
приобретать навыки их классификации, вначале пользуясь базовыми катего¬ 
риями, такими, как собаки, кошки и игрушки |20|. Позднее ребенок осоз¬ 
нает более общие категории, такие, как животные и более специфические 
(как колли, доги, гончие) |21 |. 


Проблемы классификации 

На рис. 4-1 показаны 10 изображений поездов, пронумерованных от 
А до J. Каждое изображение состоит из поезда и нескольких вагонов. 
Прежде чем продолжать чтение, попытайтесь за 10 мин определить не¬ 
сколько групп изображений, составленных по какому-то логическому при¬ 
знаку. Например, изображения можно разбить на три группы: в одной 
группе поезда имеют черные колеса, в другой группе — белые колеса, в 
третьей — и белые, и черные. 

Этот пример приводится из работ Степа и Михальского о концепту¬ 
альном объединении [191. Очевидно, что «правильного» разбиения на 
группы не существует. Наши изображения были классифицированы 93 
различными способами. Наиболее распространенный способ классификаций 
по длине состава: были выделены три группы: составы с двумя, тремя и 
четырьмя вагонами. Второй по популярности вид классификации — клас¬ 
сификация по признаку цвета колес поезда. Сорок из девяносто трех ви¬ 
дов классификации были уникальными. В нашем эксперименте большин¬ 
ство опрошенных предлагали одну из двух наиболее популярных видов 
классификации (по длине состава и цвету колес поезда). Один опрошен¬ 
ный определил две группы изображений: в одной группе составы помече¬ 
ны буквами, нарисованными с помощью только прямых линий (А, Е, F, 
Н и 1), в другой — буквами с кривыми линиями. Это, действительно, 
пример нс тривиального мышления. 

Можно изменить условие. Представим, что круги обозначают груз с 
токсичными веществами, прямоугольники — лесоматериалы, все осталь¬ 
ные знаки обозначают пассажиров. Попытайтесь теперь классифицировать 
изображения (очевидно, что новые знания изменят тип классификации). 

При таких дополнительных сведениях большинство опрошенных пред¬ 
лагали новую классификацию, основанную на признаке, — содержит со¬ 
став токсичный груз или нет? В заключение можно сказать, что новые 
сведения об области применения позволяют представить более разумную 
классификацию. 




134 


Концепции 



Разные наблюдатели по-разному классифицируют один и тот же объект. 

Суммируя сказанное выше, можно заключить, что для метода классиче¬ 
ского распределения по категориям наличие свойства является основным 
критерием схожести объектов. При этом объекты можно разделить на непе- 
ресекающиеся множества, определив для каждого — обладает он конкретным 
свойством или нет. По предположению Мински: «Наиболее подходящий на¬ 
бор свойств для такой классификации характеризуется высокой независимо¬ 
стью этих свойств относительно друг друга. Это объясняет популярность та¬ 
кого набора свойств, как размер, цвет, форма и материал. Поскольку такие 
свойства независимы, мы можем применять их в любой комбинации» [22]. 
В более общем смысле свойства не обязательно могут определяться только 
измеряемыми характеристиками. Например, то, что птицы могут летать, а 
рыбы не могут, и есть то свойство, по которому можно отличить орлов от 
семги. 

Конкретные свойства, которые необходимо выделить при классификации, 
определяются решаемой проблемой. Например, цвет автомобиля является 
важным свойством для какой-нибудь заводской системы контроля, но абсо¬ 
лютно неважен для программной системы, управляющей городскими светофо¬ 
рами. Вот почему мы утверждаем, что нет абсолютных критериев совершен¬ 
ства, хотя для конкретного примера некоторые структуры более пригодны, 
чем остальные. Джеймс утверждает, что «ни одна схема классификации не 
в состоянии представить структуру и порядок вещей в природе. Природа от¬ 
несется совершенно безразлично ко всем нашим методикам ее описания. Не¬ 
которые классификации будут более совершенны, чем другие, но только от¬ 
носительно наших интересов» [23 ]. 
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Рис. 4-1. Проблема классификации. 

Концептуальное объединение. Концептуальное объединение — более со¬ 
временная вариация классического подхода. Она возникла из попыток фор¬ 
мального представления знаний. Степ и Михальски утверждают, что при та¬ 
ком подходе сначала формируются концептуальные описания классов и за¬ 
тем объекты классифицируются согласно описанию, тем самым образуя клас¬ 
сы [24]. Например, мы можем предложить концепцию «песня про любовь». 
Эта концепция непригодна для успешного классического распределения по 
категориям, поскольку трудно заключить — какая песня больше про лю¬ 
бовь. Но тем не менее, если мы утверждаем, что песня скорее про любовь, 
чем про другое, то мы помещаем се в категорию «песня про любовь». Та 
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кое распределение объектов по классам имеет явно выраженные вероятност¬ 
ные свойства. 

Теория прототипирования. Классическое распределение по категориям и 
концептуальное объединение — достаточно мощные методы и вполне 
пригодные для проектирования сложных программных систем. Но все же 
есть ситуации, в которых эти методы не работают. Рассмотрим более совре¬ 
менный метод классификации, теорию прототипов [25]. 

Существуют некоторые абстракции, которые не имеют ни четких 
свойств, ни четкого определения. По утверждению Витгейнстайна, существу¬ 
ют категории (например, игры), которые не соответствуют классически обра¬ 
зцам, так как нет признаков, свойственных всем играм. По этой причине 
их можно объединить так называемой семейственной схожестью. Витгейн- 
стайн утверждает, что у категории игр нет четкой границы. Категорию 
можно расширить и включить новые виды игр при условии, что они опре¬ 
деленным образом соответствуют уже существующим играм [26]. При такой 
классификации класс определяется одним объектом-прототипом и объект 
можно включить в класс при условии, что он определенным образом похож 
на прототип. 

Классификация и измененный объектно-ориентированный дизайн. Раз¬ 
работчику, озабоченному постоянно меняющимися требованиями к системе и 
страдающему от ограниченности ресерсов и необходимости выполнения насы¬ 
щенных планов, предмет нашего обсуждения может показаться далеким от 
реальности. В действительности такой подход к классификации имеет непос¬ 
редственное отношение к объектно-ориентированному проектированию. На 
практике мы идентифицируем классы и объекты исходя прежде всего из 
свойств рассматриваемой проблемной области. Подобные абстракции обычно 
легко можно выделить, так как они являются непосредственной частью сло¬ 
варя проблемной области [27]. Если с помощью этого подхода не удается 
составить приемлемую структуру, приходится концептуально группировать 
объекты. Если теперь мы не сможем достаточно адекватно смоделировать за¬ 
дачу, тогда придется прибегнуть к классификации с помощью ассоциативных 
методов, выделяя группы объектов по признаку сходства их с некоторым 
объектом-прототипом. Эти три способа классификации составляют теоретиче¬ 
скую основу объектно-ориентированного анализа груііп и различных других 
методов, которые мы можем применить для идентификации классов и объек¬ 
тов при проектировании сложной программной системы. 

Объектно-ориентированный анализ 

Границы между стадиями анализа и проектирования размыты, но реша¬ 
емые ими задачи определяются достаточно четко. В процессе объектно-ори¬ 
ентированного анализа мы моделируем проблему, определяя классы и объек¬ 
ты, которые формируют словарь проблемной области. При объектно-ориенти¬ 
рованном проектировании мы находим абстракции и механизмы, обеспечива¬ 
ющие правильное поведение нашей модели. Таким образом, при разработке 
системы процесс проектирования продолжает работу, начатую на стадии ана¬ 
лиза. Шклаер и Меллор определили источники и кандидатов для классов и 
объектов [28]: 

* Материальные предметы Автомобили, телеметрические датчики, датчики 
давления 

Мать, учитель, политик 


* Роли 
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♦ События Посадка, прерывание, требование 

♦ Взаимодействие Заем, собрание, пересечение 


При моделировании систем баз данных Росс предлагает свой аналогич¬ 
ный список [29]: 


* Люди 

* Места 

* Вещи 

* Организации 

* Концепции 

* События 


Человек, с ограниченной функциональной обя¬ 
занностью 

Площади, зарезервированные для людей или 
предметов 

Материальный предмет или группа предметов 
Формально организованная совокупность людей, 
ресурсов, оборудования, имеющая определенную 
цель. Существование организации не зависит от 
индивидуумов 

Абстрактные принципы и идеи, предназначенные 
для организации работы 

События, влияющие на ситуацию в определен¬ 
ное время, или события, выступающие в роли 
звена в последовательности событий 


Коуд и Йордан предположили еще ряд источников потенциальных клас¬ 
сов и объектов [30]: 


* Структура 

* Другие системы 

* Приборы 

* Запомненные события 

* Разыгрываемые роли 

* Местоположение 

* Организации 


Взаимосвязь по составу и номенклатуре 
Внешние системы, с которыми взаимодействует 
наша прикладная область 
Приборы, работающие в нашей области 
Исторические события, которые необходимо учи¬ 
тывать 

Роли, в которых находятся пользователи 
Физическое расположение 

Группы, к которым принадлежат пользователи 


На более высоком уровне абстракции Коуд вводит понятие предметной 
области, которая в сущности является логически связанной группой классов, 
имеющих отношение к более высоким по уровню функциям системы. 

Прикладной анализ 

Методы прикладного анализа аналогичны методам объектно-ориентиро¬ 
ванного анализа. Обычно объектно-ориентированный анализ применяется для 
решения какой-то конкретной проблемы, а прикладной анализ — для по¬ 
иска общих классов и объектов, свойственных всем применениям внутри 
определенной сферы приложения, таких, как ракетные системы, компилято¬ 
ры, отчетная документация. Если в процессе проектирования системы воз¬ 
никли трудности в определении ключевых абстракций, прикладной анализ 
может помочь, указав на абстракции, которые были определены в родствен¬ 
ных системах. 



Идея проведения прикладного анализа впервые была предложена Ней- 
бором. Мы определим прикладной анализ как попытку выделить те объекты, 
операции, связи, которые эксперты данной области считают наиболее важ¬ 
ными [31 ]. Муре и Бейлин определяют следующие этапы в прикладном 
анализе [32]: 

* «Построение каркаса модели после консультаций с экспертами. 

* Изучение существующих систем данной области и представление приобре¬ 
тенных знаний. 

* Определение схожести и различий между системами после консультаций с 
экспертами. 

* Пересмотр модели для описания существующих систем». 

Прикладной анализ можно применить к аналогичным применениям 
(вертикальный прикладной анализ) или к связанным частям одного и того 
же применения (горизонтальный прикладной анализ). Например, если мы 
начинаем проектировать систему учета пациентов, имеет смысл рассмотреть 
уже имеющиеся подобные системы, чтобы понять, какие ключевые абстрак¬ 
ции и механизмы, использование в них, будут полезны нам. Аналогично 
система отчета и документации должна представлять различные виды отче¬ 
тов. Рассматривая отчеты как некоторую прикладную сферу, прикладной 
анализ может привести разработчика к пониманию ключевых абстракций и 
механизмов, которые обслуживают все виды отчетов. Полученные таким об¬ 
разом классы и объекты представляют собой множество ключевых абстрак¬ 
ций и механизмов, отобранных с учетом исходной задачи создания системы 
отчетов. Поэтому окончательный проект будет проще. 

Определим теперь, кто такой эксперт? В роли эксперта часто выступает 
просто пользователь системы, например инженер или диспетчер. Он 
необязательно должен быть программистом, но должен быть близко знаком с 
исследуемой проблемой и разговаривать на языке этой проблемы. Менедже¬ 
ры проектов заинтересованы в непосредственном сотрудничестве пользовате¬ 
лей и разработчиков системы. Но для очень сложных систем прикладной 
анализ является формальным процессом, для которого требуется большое 
число экспертов и разработчиков на длительный период времени. 

На практике такой формальный анализ требуется редко. Обычно для 
начального уяснения проблемы достаточно короткой встречи экспертов и 
разработчиков. Удивительно, как мало информации требуется для продуктив¬ 
ной работы разработчика. Однако мы считаем чрезвычайно полезным такие 
встречи в течение всей разработки. 

Альтернативные подходы 

Объектно-ориентированный анализ и прикладной анализ — методы ана¬ 
лиза, которые мы выбрали для объектно-ориентированного проектирования. 
Но существуют еще два альтернативных подхода, которые заслуживают об¬ 
суждения. 

Метод неформального описания. Первая альтернатива — чрезвычайно 
простой метод, впервые предложенный Эбботом. По этому методу в описа¬ 
нии проблемы подчеркиваются существительные и глаголы [331. Существи¬ 
тельные представляют собой кандидатов для классов, а глаголы — кандида¬ 
тов для операций над классами. Метод можно автоматизировать, и такая 
система была построена в Токийском технологическом институте в Фиджит- 
су [34]. 
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Подход Эббота полезен, так как он прост и заставляет разработчика 
сформировать словарь проблемы. Однако он непригоден для решения 
достаточно сложных проблем. Человеческий язык —- очень неточное средство 
выражения, потому список объектов и операции зависит от умения разра¬ 
ботчика записывать свои мысли. Тем более для многих существительных 
можно найти соответствующую глагольную форму, и наоборот. 

Структурный анализ. Вторая альтернатива определения классов и объ¬ 
ектов использует возможности структурного анализа для целей объектно-ори¬ 
ентированного проектирования. Такой подход привлекателен потому, что 
много аналитиков применяют этот подход и имеется много программных 
средств, поддерживающих структурный анализ. 

После проведения структурного анализа мы уже имеем модель системы, 
описанную диаграммами потока данных и другими результатами структурно¬ 
го анализа. Эти диаграммы обеспечивают нас разумной формальной моделью 
проблемы. Исходя из этой модели, мы можем приступить к определению 
классов и объектов нашей проблемы тремя различными способами. 

Макменамен и Палмер предлагают сначала приступить к формированию 
словаря данных и затем к анализу контекстных диаграмм модели. Они ут¬ 
верждают, что «рассматривая список основных структур базы данных, 
следует подумать, о чем они говорят или что описывают. Например, если 
они прилагательные, то какие существительные они описывают. Ответы на 
такие вопросы могут пополнить ваш словарь». Эти кандидаты для классов 
определяются из окружающей среды, входа и выхода системы, ее ресурсов. 

Следующие два способа включают анализ диаграммы потоков данных, 
где кандидаты для объектов могут быть определены из следующих источни¬ 
ков [36 ]: 

* Внешние события и объекты. 

* База данных. 

* Поток управления. 

* Преобразование потока управления. 

Кандидаты для классов определяются из двух источников: 

* Потоки данных. 

* Поток управления. 

Преобразование данных мы можем рассматривать как операции над су¬ 
ществующими объектами или как поведение некоторого объекта, который мы 
специально создали для обоснования преобразования данных. 

Сейдвиц и Старк предлагают еще один метод, который они называют 
абстрактным анализом. Метод базируется на идентификации основных сущ¬ 
ностей, которая по природе аналогична основным преобразованиям в струк¬ 
турном анализе. «В структурном анализе входные и выходные данные изу¬ 
чаются до тех пор, пока они нс достигнут высшего уровня абстракции. 
Процесс преобразования входных данных в выходные есть основное преобра¬ 
зование. В абстрактном анализе разработчик делает то же самое, а также 
изучает основное преобразование для того, чтобы определить, какие процес¬ 
сы и состояния представляют наилучшую абстрактную модель систе¬ 
мы» [37]. После определения основной сущности в диаграмме потоков дан¬ 
ных абстрактный аналитик приступает к изучению всех поддерживающих 
систем, прослеживая входящие и исходящие потоки данных из центра, груп¬ 
пируя процессы и состояния, встречающиеся по пути. Сейдвиц и Старк на¬ 
шли абстрактный анализ слишком сложным и как альтернативный предлага¬ 
ют объектно-ориентированный анализ |38 |. 
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Необходимо отметить, что принципы структурного проектирования и 
анализа ортогональны принципам объектно-ориентированного проектирования. 
Наш опыт показывает, что структурный анализ может быть полезен в про¬ 
цессе объектно-ориентированного проектирования, но при условии, что раз¬ 
работчик не отдает предпочтение структурному типу мышления. Другая 
опасность анализа заключается в том, что многие аналитики любят рисовать 
диаграммы потоков данных, которые отражают скорее проект, чем модель. 
Очень трудно построить объектно-ориентированную модель, если она легко и 
очевидным образом поддается алгоритмической декомпозиции. Поэтому мы 
предпочитаем объектно-ориентированный анализ и анализ проблемной обла¬ 
сти как подготовительный этап для объектно-ориентированного проектирова¬ 
ния. При этом уменьшается риск испортить проект элементами алгоритмиче¬ 
ского анализа. Если же необходимо применить структурный анализ, не сле¬ 
дует писать диаграммы потоков данных, если они начинают представлять 
собой проект системы, а не существенную часть модели. Разумно избегать 
элементов структурного анализа, когда проектирование находится на 
последнем этапе. Необходимо также понимать, что различные компоненты 
проекта, полученные на этапе разработки (такие, как диаграммы потоков), 
не представляют собой какого-то конечного продукта, а всего лишь проме¬ 
жуточное средство, необходимое для понимания разработчиком проблемы. 
Обычно пишутся диаграммы потоков данных, а затем разрабатываются меха¬ 
низмы, обеспечивающие необходимое поведение системы, т.е. сам акт проек¬ 
тирования видоизменяет начальную модель. Поддержка модели в соответст¬ 
вии с проектом — работа рутинная и трудная, к тому же вряд ли необхо¬ 
димая. Таким образом, может сохраниться только продукт структурного ана¬ 
лиза высокого уровня абстракции. Он охватывает модель проблемы и может 
служить основой для многих проектов. 

4.3. КЛЮЧЕВЫЕ АБСТРАКЦИИ И МЕХАНИЗМЫ 
Определение ключевых абстракций 

Нахождение ключевых абстракций. Ключевые абстракции — это класс 
или объект, который определяет часть словаря проблемной области. Самая 
главная роль ключевых абстракций заключена в том, что они определяют 
границы нашей проблемы: выделяют вещи, существующие в нашей системе 
и поэтому важные для нас, и затеняют моменты системы, которые излиш¬ 
ни. Задача выделения таких абстракций — задача, специфичная для каждой 
проблемной области. Как утверждает Голбсри: «Соответствующий выбор объ¬ 
ектов зависит от области приложения и точности представления информа¬ 
ции» [39]. 

Определение ключевых абстракций включает в себя два процесса: 
открытие и изобретение. Мы распознаем абстракции, используемые специа¬ 
листами по предметной области; если эксперты используют эту абстракцию 
в своей речи, тогда она важна [40]. Изобретая, мы создаем новые классы и 
объекты, не являющиеся существенной частью предметной области, но по¬ 
лезные инструменты при реализации проекта. Например, пользователь авто¬ 
матического секретаря применяет термины «отчеты», «депозиты», «изъятия»; 
эти термины — часть словаря предметной области. Разработчик такой систе¬ 
мы использует те же абстракции, но вводит и свои, такие, как база дан¬ 
ных, экранный диспетчер и т.д. — ключевые абстракции проектирования, а 
не предметной области. 
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Наиболее мощный способ определения ключевых абстракций — найти в 
проблеме ключевые абстракции, аналогичные существующим классам и объ¬ 
ектам. Так как это проблема классификации, мы можем использовать клас¬ 
сические и современные способы классификации, описанные выше. 

Пересмотр ключевых абстракций. Определив некоторый набор кандида¬ 
тов для ключевых абстракций, мы должны отобрать лучшие по критериям, 
описанным в предыдущих главах. По словам Страустрапа: «Часто это озна¬ 
чает, что программист должен задаваться вопросами: Как создаются объекты 
класса? Можно ли копировать или уничтожать объекты данного класса? Ка¬ 
кие операции могут быть выполнены над этим объектом? Если ответы на 
эти вопросы туманны, то возможно общая концепция не точна и лучше 
еще раз пересмотреть, прежде чем заняться реализацией проекта* [41]. 

Определив новые абстракции, мы должны найти их место в контексте 
уже существующих классов и объектов. Подобное определение не имеет чет¬ 
ко выраженного стиля, такого, как при проектировании сверху вниз или 
снизу вверх. Халберт и О’Брайен утверждают, что «нет особой необходимо¬ 
сти строить иерархию классов, начиная с самого верхнего класса, и потом 
дополнить подклассами. Чаще вы создаете несколько независимых классов, 
осознаете их общие черты и выделяете их в нескольких суперклассах. Не¬ 
сколько таких проходов вверх и вниз по иерархии вполне достаточно для 
создания программного проекта» |42]. Это замечание — не рекомендация 
для действий, а всего лишь наблюдение, основанное на опыте и подтвержда¬ 
ющее тот факт, что объектно-ориентированное проектирование — процесс 
последовательный и итеративный. 

Трудно сразу расположить классы и объекты на правильном уровне абс¬ 
тракции. Иногда мы находим в готовой классификации похожие подклассы 
и можем их передвинуть вверх в иерархии классов, таким образом увеличи¬ 
вая степень разделяемости общих свойств [43]. Аналогично можем найти 
классы со свойствами настолько общими, что происходит семантический раз¬ 
рыв между ними и их подклассами [44]. В обоих случаях мы пытаемся 
найти зависимые и независимые абстракции. 

Программисты часто легкомысленно относятся к правильному наимено¬ 
ванию классов и объектов, но на самом деле очень важно уловить в обоз¬ 
начении классов и объектов сущность описываемых ими предметов. Програм¬ 
мы необходимо писать тщательно, как английскую прозу, не забывая чита¬ 
телей и компьютер. Рассмотрим имена, необходимые для идентификации од¬ 
ного объекта, — имя объекта, имя его класса, имя модуля, в котором этот 
класс объявлен. Учитывая, что таких объектов может быть тысяча, возника¬ 
ет проблема именования объектов. 

Мы предлагаем следующие правила: 

* Объекты называются подходящими фразами: 

TheSensor или AShape. 

* Классы называются общими существительными: 

Sensors, Shapes. 

* Операции-модификаторы определяются соответствующими глаголами: 

Draw, Move. 

* Операции-селекторы определяются вопросом или глагольной формой глаго¬ 
ла «to be»: 

ExtentOf, isOpen. 
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Определение механизмов 

Нахождение механизмов. При разработке системы Джексона (Jackson System 
Development) [45] сначала были найдены ключевые абстракции, описываю¬ 
щие модель реальности, и только затем добавлены механизмы поведе¬ 
ния [46]. Как уже говорилось выше, мы используем термин «механизм», 
чтобы описать некоторую структуру, с помощью которой объекты взаимодей¬ 
ствуют между собой, обеспечивая необходимое поведение системы. Проект 
классов воплощает в себе знания о поведении классов. Проектирование ме¬ 
ханизмов соответствует решению задачи взаимодействия объектов. 

Например, рассмотрим требование, предъявляемое к автомобилю: нажа¬ 
тие на акселератор должно приводить к увеличению оборотов двигателя. 
Как это происходит, водителю совершенно неинтересно. Для реализации 
требования можно применить любой механизм и его выбор — дело вкуса 
разработчика. Например, можно выбрать любой из предложенных ниже ин¬ 
женерных решений: 

* Механическая связь между акселератором и карбюратором (обычное реше¬ 
ние). 

* Электронная связь датчика давления, находящегося под педалью акселера¬ 
тора и карбюратора. 

* Бак с горючим находится на крыше автомобиля и топливо свободно течет 
в двигатель. Поток топлива регулируется специальной заслонкой. Нажатие 
на педаль акселератора перекрывает заслонкой поток топлива в двигатель. 

Какую именно реализацию выберет разработчик, зависит от таких 
параметров, как стоимость, надежность, технологичность и т.д. 
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С помощью механизмов объекты взаимодействуют друг с другом и 
обеспечивают таким образом более высокий уровень поведения системы. 

Пользователь не должен нарушать правила пользования устройством, 
также и объекты должны вести себя в соответствии с реализацией их меха¬ 
низмов. Водитель был бы удивлен, если бы, нажав на педаль акселератора, 
он включил фары. 

Ключевые абстракции определяют словарь проблемной области, механиз¬ 
мы определяют суть проекта. В процессе проектирования разработчик дол¬ 
жен принимать во внимание не только структуру классов, но и то, как 
объекты этих классов взаимодействуют друг с другом. Если программист 
разработал какой-то конкретный механизм взаимодействия, он реализуется 
определением методов для объектов соответствующих классов. 

Определение, механизма представляет собой стратегическое решение. 
Аналогично проектирование структуры классов тоже стратегическое решение 
в противоположность проектированию интерфейса какого-то одного класса. 

Стратегические решения должны проводиться в проекте явно и четко, 
иначе мы можем получить большое число независимых объектов, выполняю¬ 
щих свои функции без учета окружающих объектов. В наиболее элегантных 
быстрых программах воплощены тщательно разработанные механизмы. 

Примеры механизмов. Рассмотрим механизм рисования, обычно приме¬ 
няющийся в графических интерфейсах пользователя. Для того чтобы пред¬ 
ставить какой-либо рисунок на экране, пользователю необходимо обеспечить 
взаимодействие ряда объектов просматриваемой модели и некоторого клиен¬ 
та, который знает когда (но не как) отображать на экране эту модель. 
Сначала клиент дает окну команду нарисовать себя. Так как окно может 
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включать в себя ряд подокон, оно в свою очередь приказывает каждому из 
них нарисовать себя. Каждое подокно посылает далее сообщение своей моде¬ 
ли нарисовать себя, в результате чего и появляется изображение на экране. 
В этом механизме модель полностью отделена от окна и подокна, в котором 
оно представлено: подокна могут посылать сообщения к моделям, но модели 
не могут посылать сообщения подокнам. Smalltalk использует вариант этого 
механизма, названный модель рисунок контроллер (МРК) [47]. 

Механизмы, таким образом, представляют другой уровень повторного 
использования в проектировании более высокий, чем повторное использова¬ 
ние индивидуальных классов. Метод МРК, например, является основой ин¬ 
терфейса пользователя в языке Smalltalk. Этот метод строится на механизме 
зависимостей, которым обладает базовый класс языка Smalltalk, класс Object 
и который, таким образом, часто используется библиотекой классов языка 
Smalltalk. 

Примеры механизмов можно найти во многих системах. Структуру опе¬ 
рационной системы, например, можно описать на высоком уровне абстрак¬ 
ции по тем механизмам, которые используются для диспетчеризации про¬ 
грамм. Система может быть монолитной (как MS-DOS), организованной как 
наращиваемое ядро (UNIX) или как иерархия процессов (операционная сис¬ 
тема THE) [48]. В системах с искусственным интеллектом использованы 
разнообразные механизмы принятия решений. Одним из наиболее распостра- 
ненным является механизм рабочей области, в котором каждый индивиду¬ 
альный источник знаний независимо изменяет рабочую область. В таком ме¬ 
ханизме не существует центрального контроля, но любое изменение в рабо¬ 
чей области может явится толчком для разработки системой нового пути ре¬ 
шения поставленной задачи [49 ]. 

На этом завершается наше изучение классификации и понятий, являю¬ 
щихся основой объектно-ориентированного проектирования. Следующие три 
главы посвящены самому методу, в частности системе обозначений, процессу 
проектирования и рассмотрению практических примеров. 

Заключение 

* Идентификация классов и объектов — одна из важных задач объектно- 
ориентированного проектирования. 

* Классификация — в основном есть проблема группирования объектов. 

* Классификация — последовательный и итеративный процесс, трудности 
классификации обусловлены в основном широким выбором возможных ре¬ 
шений. 

* Три подхода классификации включают классическое распределение по ка¬ 
тегориям (группирование по свойствам), концептуальное объединение 
(группирование по некоторой концепции) и теорию прототипов (группиро¬ 
вание объектов по некоторым признакам схожести с прототипом). 

* Кандидаты для классов и объектов берутся из реальных объектов, собы¬ 
тий, возможных ролей и взаимодействий. 

* Прикладной анализ определяет классы и объекты по свойству их присут¬ 
ствия в различных применениях в данной прикладной области. 

* Ключевые абстракции отражают словарь проблемы. 

* Механизмы — существенный момент проекта; и определяют взаимодейст¬ 
вие различных объектов системы. 
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Дополнительная литература 

Проблема классификации вечна. В работе «Statesman» Платон описывает 
метод классификации, группируя объекты с одинаковыми свойствами. В ра¬ 
боте «Категории» Аристотель затрагивает эту же тему и анализирует разли¬ 
чия между классами и объектами. Несколько веков спустя Акуинас в работе 
«Summa Theologica» и Декарт в «Rules for the Direction of the Mind» также 
рассматривают философские вопросы классификации. 

Классификация — присущая человеку способность. Теории, касающиеся 
способности человека классифицировать в детском возрасте, рассмотрены 
Piaget и Маіег [А, 1969). Lefrancois [А, 1977] предлагает вполне доступное 
введение в этот вопрос и вполне понятную теорию восприятия ребенком 
концепции объектов. 

Многие ученые-когнитивисты подробно исследовали проблемы классифи¬ 
кации. Hewell и Simon [А, 1972] предлагают оригинальный материал по 
этой теме. Информацию по этому вопросу можно получить из работ у 
Simon [А, 1982], Hofstadter [I, 1979], Siegler и Richards [А, 1982] и 
Stillings, Feinstein, Garfield, Rissland, Rosenbaum, Weisler и Baker-Ward [A, 

1987] . Lakoff [A, 1987], будучи лингвистом, изучает вопрос влияния трудно¬ 
стей, связанных с классификацией на развитие человеческой лексики, и по¬ 
казывает, как эти исследования объединяют некоторые вопросы, связанные с 
человеческим мозгом. Minsky [А, 1986] подходит к этому вопросу с другой 
стороны, начиная с исследования структуры мозга. 

Когнитивисты используют термин «концептуальное группирование», 
пользуясь им для представления знаний через классификацию. Концептуаль¬ 
ное группирование подробно рассмотрено в работах Michalski и Stepp [А, 
1983, 1986], Pckham и Sowa [А, 1984]. 

Проблемный анализ является средством нахождения ключевых абстрак¬ 
ций и механизмом определения словаря проблемной области. Iskoe [В, 1988] 
внес большой вклад в эту область. Дополнительная информация может быть 
найдена в работах Iscoe, Browne, и Weth [В, 1989], Moore и Bailin [В, 

1988] , и Arango [В, 1989]. 

Определение классов и объектов может последовать после нахождения 
ряда различных моделей, которые удовлетворяют требованиям проблемной 
области. Abbott [F, 1983] предлагает начать поиск классов, проведя тексту¬ 
альное описание проблемной области. Ward [В, 1989] и Сайдевик 

(Seidewitz) и Stark [F, 1986] предлагают начать со структурного анализа 
диаграмм потока данных. Veryard [В, 1984] изучает эту проблему путем 
моделирования данных. 

Математики пытались спроектировать новый подход к классификации, 
подводя ее близко к так называемой теории меры. Stevens [А, 1946] и 
Coombs, Raiffa и Thrall [А, 1954] предлагают работы по этому направле¬ 
нию. 

Classification Society of North America издает два журнала в год, кото¬ 
рые содержат статьи, освещающие проблемы классификации. 


10 Гради Буч 
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МЕТОДОЛОГИЯ 

Нельзя заранее предсказать, какие нововведения будут 
успешными, а какие — неудачными. Решив спроектировать 
что-то новое (мост, самолет или небоскреб), инженер стоит 
перед необходимостью выбора из множества альтернатив. 
Возможно, он решит воплотить в своем проекте все лучшие 
черты прошлых проектов, но, возможно, попытается улуч¬ 
шить некоторые характеристики системы. 

Генри Петроски (Henry Petroski) 
То Engineer is Human 

Глава 5 

Система обозначений 

Проектирование — это не рисование диаграмм; диаграммы — всего 
лишь зарисовка проекта. Если вы понаблюдаете за работой инженера — 
программиста, механика, химика, архитектора, — вы скоро поймете, что 
сам проект находится в голове разработчика, и только иногда фрагменты 
проекта записываются на листочках бумаги [1 ]. 

Тем не менее хорошо определенная система обозначений имеет важное 
значение. Во-первых, стандартное описание проекта понятно другим разра¬ 
ботчикам, и процесс обсуждения проекта упрощается. Электрические схемы 
символ транзистора, понятны электротехникам всего мира. Аналогично про¬ 
ект жилого дома, разработанный архитекторами в Нью-Йорке, будет поня¬ 
тен строителям в Сан-Франциско. Во-вторых, «хорошая нотация освобождает 
ум от рутинной работы и позволяет сконцентрироваться на более сложных и 
необходимых работах» [2]. В-третьих, четкая система обозначений может ос¬ 
вободить разработчика от рутинной проверки на корректность и состоятель¬ 
ность — эту работу выполняют автоматические устройства. Разработка про¬ 
граммного обеспечения всегда будет трудоемкой работой. «Машины будут 
выполнять «черную» работу, а разработка концепций развития — прерогати¬ 
ва человека. Нельзя автоматизировать проектирование концепций структуры, 
но можно упростить работу описания этой структуры» [3]. 

5.1. ЭЛЕМЕНТЫ СИСТЕМЫ ОБОЗНАЧЕНИЙ 
Необходимость различных точек зрения 

Нельзя представить все детали сложной программной системы в диаг¬ 
рамме одного типа. Необходимо понимать как функциональные, так и 
структурные свойства объектов. «Необходимо понимать таксонометрическую 
структуру класса объектов, используемые механизмы наследования, индиви¬ 
дуальное поведение объектов и динамическое поведение системы в целом. 
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Архитектура 

модулей 

Архитектура 
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Физическая 
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Рис. 5-1. Модель объектно-ориентированного проектирования. 

Задача в чем-то аналогична показу футбольного или теннисного матча, 
когда требуется много камер, расположенных в разных местах спортивной 
площадки. И каждая камера передает свой аспект игры, недоступный дру¬ 
гим камерам» [4]. 

На рис. 5-1 представлены различные типы моделей (описанные в гл 1), 
которые, как мы считаем, могут оказаться необходимыми при объектно-ори¬ 
ентированном проектировании. Эти модели в совокупности позволяют разра¬ 
ботчику записать все интересные решения; они достаточно полны, чтобы 
обеспечить разработку проекта на каком-либо объектно-ориентированном или 
объектном языке. Такая система обозначений пригодна для разработок про¬ 
грамм в сотни и миллион строк. 

Наша система обозначений — довольно подробная, но это не означает, 
что каждый ее аспект необходимо использовать. При проектировании (на¬ 
пример, в архитектуре) часто пользуются грубыми рисунками, и, только по¬ 
сле того как закончена творческая созидательная часть проекта, разработчи¬ 
ки пытаются подробно описать свой проект» [51. Следует помнить, что гра¬ 
фическая нотация — это средство документации проекта и не является за¬ 
вершающим этапом. Существует опасность слишком сильной спецификации 
отдельных решений, что может затруднить решение всей проблемы. Напри¬ 
мер, архитектор на эскизе может показать расположение выключателя, но 
точное его расположение может быть установлено только электрцком после 
тщательного осмотра здания. Если разработчики и исполнители — высоко¬ 
квалифицированные специалисты и они установили тесный деловой контакт, 
то для работы, несомненно, достаточно наброска проекта. Если исполнители 
не имеют высокой квалификации и находятся далеко от разработчиков, не¬ 
обходим более детальный эскиз проекта. Часто в программных языках ис¬ 
пользуются разные термины для описания одного и того же понятия. Систе¬ 
ма обозначений, которую мы здесь рассматриваем, не зависит от конкрет¬ 
ных языков программирования. Конечно, некоторые элементы этой системы 
могут не иметь аналогов в языке, который по ряду причин необходимо ис¬ 
пользовать при реализации проекта. В этом случае не надо пользоваться 
этими элементами. Например, в Smalltalk нельзя объявить свободную под¬ 
программу, поэтому не следует использовать утилиты классов при описании 
проекта. 
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Ниже описаны синтаксис и семантика системы обозначений объектно- 
ориентированного проектирования. В качестве примера такой системы мы 
будем использовать тепличное хозяйство на основе гидропоники (гл. 2). Мы 
здесь не объясняем, как выбираем фигуры. Эти вопросы рассмотрены в гл. 
6 и 7. В гл. 8-12 описаны применения такой системы обозначений. 

Логическая и физическая модели 

При разработке обозначений мы нашли необходимым четко отделить 
независимые стороны проектных решений. Разработчик должен уделить вни¬ 
мание следующим вопросам в объектно-ориентированном проектировании: 

* Какие классы и как они связаны между собой? 

* Какие механизмы обеспечивают взаимодействие объектов? 

* В каком месте необходимо объявлять классы и объекты? 

* Какому процессору приписать конкретный процесс, как управлять процес¬ 
сами? 

Ответы на эти вопросы можно представить в виде следующих четырех 
диаграмм: 

* диаграмма класса. 

* диаграмма объектов. 

* диаграмма модулей. 

* диаграмма процессов. 

Эти четыре диаграммы составляют основу системы обозначений объект¬ 
но-ориентированного проектирования. 

Первые две диаграммы — часть логического представления системы, по¬ 
тому что они служат для описания ключевых абстракций проекта. Послед¬ 
ние две диаграммы — часть физической структуры системы, потому что они 
описывают конкретные программные и аппаратные компоненты реализации 
проекта. 

Статическая и динамическая модели 
Четыре диаграммы являются статическими. Программные системы по 
сути являются динамическими, так как в программе объекты создаются и 
уничтожаются, посылают друг другу сообщения. Описание динамической сис¬ 
темы с помощью статических рисунков — задача сложная, но она возникает 
в каждой научной дисциплине. В объектно-ориентированном проектировании 
для описания динамической компоненты мы будем пользоваться еще двумя 
дополнительными диаграммами: 

* Диаграммы переходных состояний. 

* Временные диаграммы. 

Каждый класс может иметь диаграмму переходных состояний, которая 
описывается как временная последовательность внешних событий, влияющих 
на объекты этого класса. Отдельная диаграмма объектов представляет собой 
фотоснимок текущих событий или изменяющейся конфигурации объектов. 
Поэтому необходимо вместе с диаграммой объектов описывать временную 
диаграмму Системы, в которой представлен временной порядок сообщений и 
событий. При некоторых обстоятельствах структурированный английский 
язык или выразительный PDL — вполне достойная замена для временной 
диаграммы. Кроме того, временная диаграмма или PDL могут быть исполь¬ 
зованы для документации динамического развития процесса. 
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Роль автоматизированных систем проектирования 

Плохой разработчик, обеспеченный системой автоматического проектиро¬ 
вания, может всего лишь создать плохой проект за более короткий срок. 
Хороший проект разрабатывается хорошим разработчиком, а не сложными 
автоматизированными системами. Автоматизированные системы освобождают 
разработчика от трудоемких процессов, позволяя сконцентрировать внимание 
на сложных аспектах проблемы. 

Итак, есть задачи, которые автоматизированные системы решают хоро¬ 
шо, и есть задачи, которые они не способны решить в принципе. Например, 
если мы на диаграмме объектов показали, что один объект посылает сооб¬ 
щение другому объекту, автоматизированная система может подтвердить, что 
это сообщение является частью протокола между объектами. Это пример ав¬ 
томатического контроля. Когда мы используем в диаграмме объектов опреде¬ 
ленные обозначения, для того, чтобы показать принадлежность объектов 
классам или выразить мысль, что каждый объект диаграммы есть экземпляр 
определенного класса, мы можем надеяться, что автоматизированная система 
успешно использует такие обозначения. 

Аналогично автоматизированная система может определить, что некото¬ 
рые объекты класса никогда не используются. Это пример автоматического 
контроля. Более сложная автоматизированная система может определить 
длительность конкретной операции или потенциальный дедлок между одно¬ 
временно активными объектами. Это пример автоматического анализа. Одна¬ 
ко автоматизированная система не в состоянии определить новый класс, что¬ 
бы упростить нашу структуру классов. Мы, конечно, можем, используя экс¬ 
пертные системы, попытаться построить такую автоматизированную систему, 
но для этого требуются, во-первых, эксперты как в области объектно-ориен¬ 
тированного проектирования, так и в прикладной области, и, во-вторых, 
четко определить правила теории обучения умению классифицировать и спо¬ 
собности накапливать общие знания. 

5.2. ДИАГРАММА КЛАССОВ 

Классы, взаимосвязь классов, утилиты классов 

Диаграмма классов показывает классы и их иерархию, тем самым пред¬ 
ставляя логическую сторону проекта. Отдельная диаграмма классов представ¬ 
ляет всю или часть структуры классов системы. Для небольших систем до¬ 
статочно одной диаграммы классов, для больших систем потребуется ряд та¬ 
ких диаграмм. 

Три наиболее важные компоненты структуры классов — классы, иерар¬ 
хия классов, утилиты классов (для языков, в которых определены свободные 
подпрограммы). 

Классы. На рис. 5-2 показано обозначение для представления классов 
на диаграмме. Класс обычно представляют аморфным объектом, называемым 
облаком. Так обозначают не четко описанные абстракции. Штриховая ли¬ 
ния, образующая границу, указывает, что обычно пользуются экземплярами 
этого класса, а не самим классом. Имя класса (паше) помещается внутри 
облака. Если имя класса слишком длинное, его можно сократить. Каждый 
класс должен иметь уникальное имя. 

Иерархия классов. В гл. 3 были описаны типы различных связей меж¬ 
ду классами: наследование, связь по типу использования, наполнение и 
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связь между метаклассами. Для усиления концепции иерархии классов мы 
использовали понятие «неопределенное взаимодействие». Обозначения для 
каждого типа связи между классами представлены на рис. 5-3. Каждое та¬ 
кое обозначение может иметь метку (не обязательно) для обозначения име¬ 
ни или роли этой связи. Если метка указана, можно использовать жирную 
точку для указания направления чтения метки. Связь по типу использова¬ 
ния обозначается двойной линией с кружком на одном конце для обозначе¬ 
ния класса, который пользуется ресурсами другого. Например, если мы ис¬ 
пользуем двойную линию, для того чтобы указать на связь между классами 
А и В и помещаем незакрашенный кружок у класса А, то утверждаем, что 
интерфейс класса А использует ресурсы класса В. Если кружок закрашен, 
то утверждаем, что реализация класса А использует ресурсы класса В. На 
ранних стадиях разработки достаточно показать связь между интерфейсами, 
при реализации проекта можно будет добавить связь между реализациями 
классов. 

При некоторых обстоятельствах, особенно при моделировании классов 
для базы данных, большое значение приобретают количественные отношения 
между классами, которые используют ресурсы друг друга. На рис. 5-3 пока¬ 
заны обозначения, которые мы используем для обозначения количественных 
отношений между классами (обозначения заимствованы из grep утилит OS 
UNIX). Например, между классами А и В, если мы поместим «1» у класса 
А и «+* у класса В, то тем самым мы утверждаем, что для каждого экзем¬ 
пляра класса А имеем несколько экземпляров класса В, и для каждого эк¬ 
земпляра класса В — один экземпляр класса А. Если необходимо, мы мо¬ 
жем сформулировать более сложные количественные отношения между клас¬ 
сами, используя знаки -, о, <, >, <= и =>. 

Для обозначения того, что класс А наполняет класс В, используется 
штриховая линия, стрелка указывает на класс, который иллюстрируют (на¬ 
пример, В). Такая связь классов используется только для языков, которые 
поддерживают параметризованные классы или обобщенные механизмы. 

Наследственная связь обозначается так же, как и наполняющая, но ли¬ 
ния сплошная. Наследственная связь наиболее популярная после связи ис¬ 
пользования. Обычно в иерархии классов не указывают самый верхний 
класс, такой, как TObject в Object Pascal, если, конечно, нет особой причи¬ 
ны. Независимые классы обозначаются без указания их принадлежности 
множеству подклассов самого верхнего класса. Если экземпляры одного клас¬ 
са несовместимы по типу с экземплярами суперкласса этого класса, то 
стрелку, соединяющую эти классы, помечают черточкой. 

Связь между метаклассами обозначается жирной линией. В некоторых 
языках, например в Smalltalk, каждый класс имеет свой метакласс, но мы 
обычно обозначаем только те метаклассы, которые определяют поведение, 
свойственное области приложения. Неопределенная связь между классами 
обозначается линией из точек. Штриховая линия применяется, если связь 
существует, но решение о типе связи отложено. 



Рис. 5-2. Обозначение класса. 
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Рис. 5-3. Обозначение отношений между классами и множественно¬ 
стью классов. 

Утилиты класса. Обозначение утилиты класса представлено на рис. 5-4. 
Оно похоже на обозначение класса, но отличается тенью. Утилиты класса 
являются общедоступными подпрограммами или множеством таких подпрог¬ 
рамм. Если программный язык не использует такие подпрограммы, такое 
обозначение можно не применять. Необходимо именовать утилиты, причем 
имена должны быть уникальными. 

0 -> 

Рис. 5-4. Обозначение утилиты классов. 

Пример диаграммы класса. На рис. 5-5 приведен пример обозначений 
тепличного хозяйства на основе гидропоники. Это лишь одна из многих ди¬ 
аграмм, необходимых для полного описания такой системы. На ней показа¬ 
но, что классы Heater (нагреватель) и Cooler (холодильник) наследуют из 
более общего класса Acluator. В реализации класса EnvironmentalController 
используются классы Heater, Cooler и Lights. Для каждого нагревателя и 
холодильника существует только один экземпляр класса Environmental- 
Controller, и для каждого экземпляра класса EnvironmentalController имеются 
только один нагреватель и холодильник. 

Для экземпляра класса EnvironmentalController может существовать п 
объектов класса Lights, но для каждого экземпляра Lights — только один 
экземпляр EnvironmentalController. На диаграмме также показан модуль сво¬ 
бодных подпрограмм, использующих ресурсы класса EnvironmentalController. 

Категории классов и видимость категорий классов 

Категории классов. Обычно диаграмма классов включает один или не¬ 
сколько десятков классов. Но большая система может содержать сотни и ты¬ 
сячи классов их невозможно поместить на одной диаграмме. Чтобы обойти 
подобные затруднения, необходимы средства описания подмножеств классов. 
Таким образом, мы приходим к понятию категория классов. 
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Рис. 5-5. Диаграмма классов тепличного хозяйства на основе гидро¬ 
поники. 


В немногих объектно-ориентированных языках классы определяются 
внутри других классов. Такая структурность редко отражает какие-то проек¬ 
тные решения, а всего лишь обеспечивает удобство реализации или ограни¬ 
чивает область видимости вложенных классов. Очень важным моментом про¬ 
ектирования является определение категорий классов (обычно известных как 
subject areas), каждая из которых представляет собой множество классов или 
других категорий классов, объединенных логическими средствами. Большин¬ 
ство объектно-ориентированных языков не имеют возможности своими сред¬ 
ствами обеспечить выделение категории, но эта процедура является сущест¬ 
венной частью проектирования. На практике большая система имеет диаг¬ 
рамму классов, состоящую из категорий классов с максимальным уровнем 
абстракции. Такая диаграмма позволяет разработчику понять общую логиче¬ 
скую структуру системы, поскольку она описывает высокоуровневую органи¬ 
зацию ключевых понятий, формирующих словарь проблемной области. Каж¬ 
дая категория классов определяет некоторую диаграмму классов; рассмотрев 
реализацию отдельной категории, мы увидим или просто диаграмму классов, 
состоящую из классов, связей, утилит, или в случае большой системы дру¬ 
гую диаграмму категорий классов. 

Обозначения категории показаны на рис. 5-6: прямоугольник с именем 
в центре. Правила именования такие же, как для классов и утилит. Как 
мы уже говорили, категория включает другую диаграмму классов или кате¬ 
горий. Диаграмма классов может содержать как категории классов, так и 
просто классы. 

Видимость категории классов. Категория классов представляет собой 
именованную область, содержащую некоторые объекты: объекты могут быть 
видимыми извне, могут быть обособленными для категории классов, некото¬ 
рые объекты могут быть импортированы из других категорий классов. Для 
обозначения видимости именованного объекта категории классов будем поль¬ 
зоваться обозначениями, показанными на рис. 5-6. Объект, имя которого не 
помечено, считается обособленным для данной категории, и поэтому на этот 



Система обозначений 


153 


объект нельзя ссылаться извне. Объект, имя которого обведено прямоуголь¬ 
ником, хоть и содержится в данной категории, но может быть экспортиро¬ 
ван, поэтому считается видимым для категорий, которые его импортируют. 
Например, предположим, что класс А экспортирован из категории X. Если 
категория классов X видима категории классов Y, то класс А видим всем 
объектам, содержащимся в классе Y. Другими словами, А импортируется в 
Y. Класс А определяется в категории X, но может появиться и в диаграм¬ 
мах классов для категории Y, причем необходимо подчеркнуть имя класса А 
в таких диаграммах. 

Взаимосвязь между категориями классов обозначается стрелкой, пока¬ 
занной на рис. 5-6. Для того чтобы показать, что категория Y импортирует 
классы, определенные в X, мы проводим стрелки от Y к X. Каждая такая 
стрелка может обозначаться именем, чтобы документировать имя и роль 
связи. 

При обозначении связи категорий с основными классами возникают 
трудности, обусловленные тем, что такие классы видимы всем частям систе¬ 
мы и нарисовать все связи будет затруднительно. Если придерживаться хо¬ 
рошего стиля, необходимо поместить все основные классы в одну категорию. 

Теперь необходимо сделать эту категорию видимой всеми категориями 
системы. Чтобы не загромождать диаграмму линиями, мы видимую всем ка¬ 
тегорию пометим словом global в левом нижнем углу прямоугольника. Это 
будет означать, что все объекты, экспортируемые данной категорией, будут 
видимы для всех категорий, которые импортируют эти объекты. 

Пример категории классов. На рис. 5-7 показана диаграмма классов, 
которая использует категории классов. Это типично организованная диаграм¬ 
ма: абстракции, имеющие физический смысл (именно, actuators и sensors), 
расположены на нижнем уровне диаграммы, абстракции по содержанию, 
близкие к потребностям пользователя, — на верхнем уровне. Категория ІРС 
(inter process control) — глобальная категория, поэтому ее ресурсы видимы 
всем категориям классов этой диаграммы. Мы можем уточнить каждую из 
шести представленных здесь категорий, для этого необходимо представить 
соответствующую диаграмму классов, такую, например, как на рис. 5-5. 

Шаблоны диаграммы классов 

Описанные выше обозначения вполне достаточны для описания структу¬ 
ры классов на высоком уровне абстракции. Просматривая диаграммы, разра¬ 
ботчик легко может понять структуру системы. Но одних диаграмм, очевид¬ 
но, не достаточно, и мы должны обеспечить пользователя более точной ин¬ 
формацией. Более конкретно, мы должны иметь средства документального 
описания каждого класса: его суперклассы, поля и операции. 


I имя і экспортируемая из категории і 
имя обособленная для категории к 

имя импортируемая из категории к 


Рис. 5-6. Обозначения категории классов и видимости. 
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Рис. 5-7. Диаграмма классов тепличного хозяйства на основе гидро¬ 
поники (высокий уровень абстракции). 

Шаблоны класса. Для каждого класса мы имеем шаблон, представлен¬ 
ный на рис. 5-8 (шаблон не следует путать с похожим шаблоном языка 
C++ для параметризованных классов). В шаблоне представлены наиболее 
важные аспекты класса, описанные в гл. 3. Шаблон подробно определяет 
класс, но совсем не обязательно заполнять его полностью. На начальном 
этапе проектирования шаблон заполняется по немногим пунктам и в про¬ 
цессе дальнейшего проектирования дополняется. Если язык, с помощью ко¬ 
торого реализуется проект, достаточно выразителен, то можно отказаться от 
описанного здесь шаблона и описать проект на языке реализации. 

Два первых пункта шаблона вполне очевидны. Третий пункт выражает 
видимость класса в его категории: экспортируемый, обособленный или им¬ 
портируемый. Следующий пункт описывает координальность класса, т.е. 
сколько экземпляров этого класса можно создать. Обычно координальность 
равна 0, 1 или п (где п — натуральное число). Место данного класса в 
иерархии системы определяется следующими двумя пунктами. В зависимости 
от языка реализации класс может иметь ноль, один и более суперклассов и 
метаклассов. В любом случае классы, перечисленные в этом пункте, показа¬ 
ны в диаграмме и приводятся в шаблоне всего лишь из соображений полно¬ 
ты и ясности шаблона. Следующий пункт определяет параметры класса, ко¬ 
торые могут быть заполнены, только если эти пункты имеют смысл для 
языка реализации (например, обобщенные параметры для Ada, макросы и 
параметризованные классы для C++). 

Следующие три пункта повторяются в шаблоне 4 раза: три раза для 
интерфейса и один раз для реализации класса. Если позволяет язык реали¬ 
зации, интерфейс класса можно разбить на три части: доступную, защищен¬ 
ную и обособленную. C++ используют все три части, Object Pascal — толь¬ 
ко доступную часть. В любом случае это очень важный пункт шаблона, по¬ 
скольку здесь описывается внешний интерфейс класса. Как описано в гл. 3, 
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внешний интерфейс класса включает описание экземпляров переменных и 
переменных класса (описанных в пункте «поле») и операций класса. Для 
каждого поля мы должны записать его имя, константа или переменная, его 
класс, диапазон, способ инициализации поля (например, поле L может быть 
описано как переменная целого типа с диапазоном изменения от 1 до 100). 
Снова отметим, что нет необходимости заполнять все пункты, можно запол¬ 
нить пункты, важные для текущего состояния проекта. Шаблон достаточно 
полон, чтобы выразить все интересные характеристики переменных. Пункт 
«операции» в действительности содержит список операций, причем каждая 
операция имеет собственный шаблон, который мы опишем вкратце. Пункт 
«использование» аналогичен пунктам «суперкласс» и «метакласс» и приводит¬ 
ся в этом месте лишь для полноты и ясности описания. Все связи по типу 
использования показаны графически на объектной диаграмме. 

На ранних стадиях проекта разработчик заполняет только доступные, 
защищенные, обособленные части шаблона. Пункты «поля» и «операции* за¬ 
полняются после со го, как сделаны соответствующие решения о способе реа¬ 
лизации проекта. 

Шаблон класса содержит четыре поля, которые документируют динами¬ 
ческую семантику, временное и пространственное поведение объектов этого 
класса. Пункт «конечный автомат» определяет диаграмму переходных состоя¬ 
ний; далее мы обсудим подробнее эту диаграмму. Пункт «параллелизм» оп¬ 
ределяет экземпляры класса как имеющие последовательный, блокирующий 
или активный тип. Конечно, этот пункт должен быть сопоставлен с парал¬ 
лельностью операций. Например, если класс заявлен как последовательный, 
его операции не могут быть защищенными, параллельными или многозадач¬ 
ными. Следующий пункт «объем памяти» описывает размер пространства па¬ 
мяти для размещения объектов этого класса. Размер может быть выражен в 
единицах памяти или в других единицах [6]. Последний пункт шаблона оп¬ 
ределяет устойчивость объектов класса. Устойчивый объект характеризуется 
тем, что может существовать после окончания программы, которая его 
создала. Временный объект существует только во время существования про¬ 
граммы. 

Суперкласс, метакласс и используемые классы показаны на диаграмме 
объектов, но они также присутствуют в шаблоне класса. Аналогично некото¬ 
рые элементы шаблона могут быть показаны в графическом представлении 
класса. Мы нашли полезным показать координальность, параллельность, ус¬ 
тойчивость классов, размещая обозначения этих признаков рядом с обозна¬ 
чением класса (как, например, для обозначения категории классов мы поме¬ 
щали в нижний левый угол признак «global»). Поэтому разработчик, про¬ 
сматривающий диаграмму объектов, сможет легко уловить важные аспекты 
проекта, такие, как абстрактность или активность конкретных классов. Еще 
раз отметим, что у разработчика нет необходимости заполнять все пункты, 
а лишь те пункты, которые необходимы для документирования важных мо¬ 
ментов проекта. 

Шаблоны утилиты/класса. Шаблон утилиты/класса показан на 
рис. 5—9. Поскольку утилита класса представляет собой набор общедоступ¬ 
ных подпрограмм (и иногда глобальные константы и переменные), шаблон 
утилиты можно определить как некоторое подмножество шаблона для клас¬ 
сов. Поля и операции, определяемые в интерфейсе утилиты, формируют 
внешний вид утилиты класса; поля и операции, ответственные за внутрен¬ 
нюю реализацию гилиты, скрываются. 



Рис. 5-9. Шаблон для утилиты классов. 

Шаблоны операции. Шаблоны класса и утилиты включают список опе¬ 
раций. Для нестрогого описания проекта достаточно представить имя опера¬ 
ции, ее параметры и семантическое описание операции (в виде текстового 
описания). Если необходимо более детальное описание проекта, можно вос¬ 
пользоваться шаблоном, представленным на рис. 5-10. 

Содержание первых двух пунктов вполне очевидно. Следующий пункт 
«категория* обеспечивает возможность группирования взаимосвязанных опе¬ 
раций (например, как это делается в языке Smalltalk) . Например, мы мо¬ 
жем сгруппировать операции, изменяющие состояние программы, в группу 
«модификаторы», а операции, не изменяющие состояние программы, в груп¬ 
пу «селекторы». В любом случае категория операций — удобное средство 
обозначений и особенно полезно в случае, если класс имеет достаточно мно¬ 
го операций. 



Рис. 5-10. Шаблон операции. 

Пункт «расширение» используется часто на языке реализации CLOS. В 
этом пункте определяется, является ли операция основным методом или это 
квалификатор :before, :after, :around. Таким образом, статический обзор опе¬ 
раций можно закончить перечислением параметров и результатов (для фун¬ 
кции). Динамические свойства операций представлены в следующих четырех 
пунктах. Мы можем определить семантику функции неформально, описав 
содержание операций на разговорном языке или же более формально описав 
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предсостояние, постсостояние и исключительные состояния. Анализ семанти¬ 
ки операции может привести к необходимости изучения диаграммы объек¬ 
тов, на которой показаны связи между объектами, участвующими в исход¬ 
ной операции. Также необходимо изучить динамическую семантику опера¬ 
ции (показанную на временной диаграмме или с помощью PDL). В любом 
случае разработчик не должен заполнять все пункты шаблона. Подробность 
шаблона диктуется текущей потребностью в документации проекта. 

Последние три пункта определяют параллельность операции, необходи¬ 
мые временные и пространственные ресурсы операций. В гл. 3 упоминалось, 
что операция может быть последовательной, т.е. имеется только один канал 
управления. Альтернативно операция может успешно выполняться в мульти¬ 
программном режиме, но с различными механизмами синхронизации (регу¬ 
лируемой, параллельной, множественной). 

Пример шаблона диаграммы классов. На рис. 5-11 показан пример 
шаблона диаграммы классов для класса Cooler и его операции turnOn. 

5.3. ДИАГРАММЫ ПЕРЕХОДА СОСТОЯНИЙ 
Состояния и переходные процессы 
Диаграмма классов не .определяет динамического поведения объектов или 
классов. Динамическое поведение объектов лучше всего представлено на ди¬ 
аграмме переходов. На этой диаграмме показаны состояния объектов, собы¬ 
тия, приводящие к переходу из одного состояния в другое, и результат пе¬ 
рехода. Диаграмма переходных процессов тесно связана с другими видами 
обозначений: шаблон класса может включать ссылку на диаграмму перехо¬ 
дов, а также действия, описанные в диаграмме переходов, могут ссылаться 
на другие диаграммы объектов. 


е окументация: 

идимость: 

Множественность: 

Иерархия: 

Суперклассы: 

Общедоступный интерфейс: 
Операции: 


Обособленный интерфейс: 
Параллельность: 


Вентилятор 

Этот класс определяет холодильник 
Обособленный 


turnOff 
turnOn: lempe 
isOn 



Имя: 

Документация: 

Формат параметра: 
Действия: 


Исключения: 

Параллельность: 


turnOn 

Включить холодильник и ожидать 
желаемой температуры 
температура 

Включает холодильник и запускает 
программу, которая периодически 
сверяет температуру с желаемой 
сбой холодильника 
блокирующая 


Рис. 5-11. Шаблон диаграммы классов для класса Cooler и его 
операции turnOn. 
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Дейстеин PDL / диаграмм о«ѵактоа 


Рис. 5-12. Обозначения для диаграммы переходных состояний. 

Состояния. Круг на рис. 5-12 обозначает конкретное состояние. В цент¬ 
ре круга — имя состояния; имя должно быть уникальным в пределах диаг¬ 
раммы переходов. 

Обычно диаграмма переходов класса не имеет стартовых и финальных 
состояний. Вновь созданный объект принимает состояние, зависящее от окру¬ 
жения; при уничтожении объекта диаграмма переходов теряет смысл. Име¬ 
ются два обозначения для стартовых и финальных состояний: стартовое со¬ 
стояние обозначается двойной окружностью, финальное — жирной окружно¬ 
стью. 

Переходный процесс. Типом связи между состояниями является пере¬ 
ходный процесс, который может приводить к переходу из одного состояния 
в другое, а также из состояния в такое же состояние. Как показано на рис. 
5-12, переходный процесс изображается стрелкой, направленной из исходного 
состояния в новое. Каждая стрелка может быть помечена именем по край¬ 
ней мере одного события, инициирующего данный переход, и именем ре¬ 
зультирующего действия. События и действия не обязательно должны быть 
уникальными в пределах одной диаграммы, поскольку одно и то же событие 
может вызвать переход в разные состояния и одно и то же действие может 
быть выполнено при разных переходных процессах. 

Шаблон диаграммы переходов 

Шаблон перехода. Так же как для классов, утилит и операций, суще¬ 
ствует шаблон перехода (рис. 5-12). Поскольку в нашем понимании переход 
ассоциируется с действием, такой вид диаграммы переходов описывается ко¬ 
нечным автоматом Мили, который противоположен конечному автомату Му¬ 
ра, где переходы ассоциированы с состоянием. 

Действия, связанные с переходом, могут быть описаны с помощью PDL 
или же ссылкой на другую диаграмму объектов. 

Пример диаграммы переходов. На рис. 5-13 показан пример диаграммы 
переходов для класса EnvironmentalController тепличного хозяйства на основе 
гидропоники. 

5.4. ДИАГРАММА ОБЪЕКТОВ 
Объекты и их взаимосвязь 

Диаграмма объектов показывает существующие объекты и их взаимо¬ 
связь в логическом проекте системы. Одна диаграмма может представлять 
часть или всю структуру объектов системы. Обычно для полного документи¬ 
рования проекта необходимо иметь несколько диаграмм. Цель каждой диаг¬ 
раммы объектов — показать семантику ключевых механизмов логического 
проекта. Классы являются статической частью проекта, а объекты при вы- 
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полнении программы могут порождаться и уничтожаться. Поэтому мы ис¬ 
пользуем диаграмму объектов, для того чтобы показать динамическую се¬ 
мантику проекта и описать конечные автоматы проекта. Диаграмма объектов 
представляет собой снимок динамических событий. В этом смысле диаграммы 
объектов прототипны: каждая из них представляет собой взаимодействия 
между множеством объектов, причем не имеет значения, какие объекты 
участвуют во взаимодействии. 

Существует важная связь между диаграммами классов и диаграммами 
объектов (аналогичная связи между классом и его объектом): каждый объект 
диаграммы объектов представляет собой экземпляр некоторого класса. Кроме 
того, операции, описанные в диаграмме объектов, должны находиться в со¬ 
ответствии с операциями соответствующего класса. Например, если показано, 
что объект R посылает сообщение М объекту S, то необходимо, чтобы опе¬ 
рация М была определена в классе объекта S. Если мы в процессе разра¬ 
ботки проекта исключили операцию N в некотором классе, то надо по¬ 
мнить, что в этом случае, возможно, потребуется исправить некоторые диаг¬ 
раммы объектов. 

Для полного документирования логического проекта системы необходимо 
совместно использовать диаграммы классов и объектов, поскольку они 
отражают независимые стороны проекта. Диаграмма классов описывает клю¬ 
чевые абстракции системы, диаграмма объектов — важные механизмы, опе¬ 
рирующие этими абстракциями. 

Два важных элемента диаграммы объектов — объекты и взаимодействие 
объектов. 

Объекты. На рис. 5-14 показано обозначение для объекта на диаграмме 
объекта. Оно похоже на обозначение класса, только здесь используем 
сплошную линию. Имя объекта не обязательно должно быть уникальным и 
даже может отсутствовать, поскольку объекты в программе могут создаваться 
динамически без указания имени. Поэтому имя объекта не обязательно 
должно быть точным и всего лишь должно отражать соответствие объекта 
какой-либо абстракции, например aCooler или aTemperatureSensor. Конечно, 
некоторые объекты могут именоваться точным осмысленным именем, напри¬ 
мер GreenHouse7 или HotWaterValueZone3. 

Свойства объекта можно описывать значками в нижнем левом углу, по¬ 
добно тому как это делалось для обозначений классов. Наиболее важными 
свойствами являются параллельность и устойчивость объекта — свойства, 
описанные в классе объекта. При таком описании объектов одного взгляда 
на диаграмму объектов достаточно, чтобы определить каналы управления 
объектами и их устойчивость. 

Связь между объектами. Связь между объектами определяется только 
возможностью одного объекта послать сообщение другому. Поскольку связь 
такого рода — двунаправленная, для ее обозначения используется ненаправ¬ 
ленная прямая линия (рис. 5-14). Мы используем сплошную линию для 
обозначения связи, которая определена в программной реализации проекта, 
и пунктирную для внешних по отношению к системе связей (например, для 
обозначения обратной связи в нагревающих и охлаждающих системах). 

На ранних стадиях разработки достаточно документировать взаимосвязь 
между классами в нестрогих и неполных формах; например, достаточно по¬ 
казать, что объекты могут посылать друг другу сообщения, но не рассматри¬ 
вать спецификации этих сообщений. 
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TemperatureChange Temperature Change 



Рис. 5-13. Диаграмма переходных состояний тепличного хозяйства на 
основе гидропоники. 

внутри системы 
вне системы 

Рис. 5-14. Обозначения для объектов и связей между объектами. 
Видимость и синхронизация объектов 

Мы можем добавить поясняющие знаки на диаграмме объектов двумя 
способами. 

Видимость объектов. Сначала мы должны уточнить, как объекты видят 
друг друга. Обозначения, освещающие этот вопрос, не всегда обязательны на 
диаграмме объектов и присутствуют только в случае необходимости. В гл. 3 
были описаны шесть различных форм видимости объектов друг другу. На 
рис. 5-15 представлены знаки, обозначающие эти формы. Например, если 
объект R разделяет поле с объектом S, то этот факт на диаграмме объектов 
обозначается соответствующим знаком, расположенным на линии, соединяю¬ 
щей R с S ближе к объекту R. Видимость объектов друг другу можно пока¬ 
зать особым пространственным расположением объектов на диаграмме. На¬ 
пример, разместив активные объекты вверху диаграммы, а пассивные объек¬ 
ты внизу. Аналогично, чтобы показать агрегативность, можно поместить 
символ одного объекта внутрь символа, обозначающего другой объект. 

Синхронизация сообщений. Очень важно показать методы синхрониза¬ 
ции взаимодействия объектов. Для этого необходимы новые обозначения. Со¬ 
общение, переданное объектом S объекту R, мы обозначаем стрелкой, прове¬ 
денной вдоль объекта, причем стрелка помечена именем сообщения. Эта 
стрелка указывает на объект, которому послано сообщение, хотя данные мо¬ 
гут передаваться в обратном направлении (например, в направлении линии 
передаются параметры сообщения, обратно — результат). 
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В одна лексическая зоне 

СЮ одна лексическая зона (общая) 
О использование параметра 
СЮ использование параметра (общее) 


задержанная 


QD использование поля (общее) 

Рис. 5-15. Обозначения для видимости объектов и синхронизации сооб¬ 
щений. 



Рис. 5-16. Диаграмма объектов тепличного хозяйства на основе 
гидропоники. 

Для систем с чисто последовательным взаимодействием стрелка является 
вполне достаточным средством описания взаимодействия объектов. Однако 
все значительно сложнее, если существует много каналов управления. На¬ 
пример, если два объекта активны одновременно, то сообщение от объекта S 
к объекту R может быть задержано (возможно, R не готов принять сообще¬ 
ние), или же может привести к фатальной ошибке (S не может долго 
ждать ответа от R). В системе, возможно, необходимы сообщения, которые 
прерывают сообщения, посланные другими объектами. В гл. 3 были обсужде¬ 
ны пять типов синхронизации сообщений: проіггая, синхронная, отсроченная, 
задержанная и асинхронная. На рис. 5-15 показаны знаки обозначения из 
работы [7]. Каждый такой знак может быть помечен списком имен сообще¬ 
ний. 

Пример диаграммы объектов. На рис. 5-16 показан пример диаграммы 
объектов. Объект aGrowingPlanController посылает два сообщения объекту 
anEnvironmentController: SetTemperature и SetLights. Это сообщение между 

11 Гради Буч 
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активными объектами и является синхронным. Также видно, что 
anEnvironmentController — поле для aGrowingPlan, но оно разделяемое, т.е. 
существуют альтернативные имена для этого объекта. 

Объект theGrowingPlans обозначает множество, состоящее из индивиду¬ 
альных объектов aGrowingPlan. Чтобы это показать, мы помещаем объекты 
aGrowingPlan внутрь theGrowingPlans. Мы используем ‘этот же прием, чтобы 
показать вложенность классов, утилит и модулей. В проекте, показанном 
здесь, объект aGrowingPlanController может послать сообщение Desired 
Temperature (селектор) любому объекту aGrowingPlan. В этом случае семан¬ 
тика передачи сообщения очевидна, поскольку объекты aGrowingPlan после¬ 
довательные. 

Шаблон диаграммы объектов 

Более полную информацию об объектах и сообщениях можно получить 
из шаблонов объектов и сообщений. 

Шаблон объекта. На рис. 5-17 показан шаблон для объекта. В шабло¬ 
не указан класс объекта, поэтому косвенно можно определить операции, ко¬ 
торые можно выполнить над объектом. Шаблон обеспечивает информацией 
об устойчивости объекта, которая в свою очередь должна соответствовать 
спецификации класса этого объекта. В частности, если в шаблоне класса 
объекта утверждается, что все экземпляры этого класса временные, то ус¬ 
тойчивость объектов может быть статической (объект существует только в 
течение жизни программы) или динамической (объект создается и уничтожа¬ 
ется во время выполнения программы). Если в шаблоне класса утверждает¬ 
ся, что экземпляры могут быть устойчивыми, то объекты этого класса могут 
быть динамическими, статическими или устойчивыми (т.е. объект существует 
после окончания программы, которая его создала). 

Шаблон сообщений. На рис. 5-17 показан шаблон для сообщений. 
Шаблон описывает операцию, определенную в спецификации класса этого 
объекта, но в тоже время представляет более детальное семантическое опи¬ 
сание. Шаблон имеет также временную информацию об операции, например 
периодичность посылки сообщения и частота посылок. Этот момент важен 
при проектировании временных ресурсов системы. 

5.5. ВРЕМЕННАЯ ДИАГРАММА 
События, упорядоченные во времени 

Сами по себе диаграммы объектов статичны. Они показывают множест¬ 
во объектов, передающих друг другу сообщения, но не показывают потоки 
управления и порядок событий. Соответствующая диаграмма переходов так¬ 
же не отвечает на поставленные вопросы, так как только определяет, какие 
изменения имеют место внутри объекта и не затрагивают взаимодействия 
между объектами. Таким образом необходимо определить средства докумен¬ 
тирования динамики посылки сообщений. Мы рассмотрим три типа такой 
документации. Первый подход очень прост. На диаграмме объектов мы по¬ 
мечаем каждое сообщение числом, равным порядковому номеру посылки 
этого сообщения. Таким образом, сообщение помеченное 1, будет послано 
первым, затем сообщение 2 и т.д. Такой способ работает хорошо, если по¬ 
рядок посылки строго задан заранее, и становится непригодным в случае ус¬ 
ловного потока контроля (т.е. если условие С верно, то посылается сообще¬ 
ние М, иначе сообщение N). В этом случае необходимо выбрать второй тип 
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документации, в котором порядок событий определяется для каждой диаг¬ 
раммы объектов на языке PDL. Язык PDL является выразительным, понят¬ 
ным и поддерживается автоматическими средствами. 

Обозначения временной диаграммы 

Временные диаграммы третьего типа документирования очень похожи на 
временные диаграммы, которыми пользуются разработчики аппаратных 
средств. На рис. 5-18 показано, как мы применяем подобные диаграммы для 
нашей цели. Видно, что наша временная диаграмма — график; по горизон¬ 
тальной оси расположены метки времени, на вертикальной расположены 
объекты. Время выражается в абсолютных величинах или в относительных. 
На вертикальной оси располагаются только те объекты, временная диаграм¬ 
ма взаимодействия которых представляется нам интересной. При движении 
по графику вдоль оси времени можно определить, какая операция выполня¬ 
ется. Например, начинаем с операции 1 для объекта R. В некоторый мо¬ 
мент реализация этой операции вызывает операцию 2 для объекта S, кото¬ 
рая в свою очередь посылает сообщение 3 объекту Т и т.д. Штриховая ли¬ 
ния на диаграмме показывает вложенность сообщений. Например, когда за¬ 
канчивается операция 3, управление передается обратно операции 2. 

Временные диаграммы полезно дополнять символом *, обозначающим 
момент создания нового объекта, и символом !, обозначающим момент унич¬ 
тожения объекта. Временная диаграмма может содержать знак создания но¬ 
вого объекта (*) и знак уничтожения объекта (!). Можно также отмечать 
тупиковые ситуации (недостаток ресурса времени). Например, мы можем 
проставить на диаграмме необходимый для операции ресурс времени (из 
шаблона операции). Если в системе существует несколько активных объек¬ 
тов и, следовательно, несколько каналов управления, то необходимо рисо¬ 
вать временную диаграмму для каждого канала управления или же описать 
каждый канал на языке PDL. Временные диаграммы в этом случае удобнее 
располагать одна над другой с одинаковыми масштабами времени по оси X. 

Обычно диаграмма объектов включает несколько временных диаграмм. 
Например, на первой временной диаграмме мы можем показать динамиче¬ 
ское поведение конкретного механизма, на второй описать асинхронные 
внешние события, на третьей определить поток управления при исключи¬ 
тельных событиях. При этом нет необходимости всегда использовать времен¬ 
ные диаграммы для каждой диаграммы объектов, но при документировании 
критической по времени активности без них трудно обойтись. 

5.6. МОДУЛЬНАЯ ДИАГРАММА 
Модули и видимость модулей 

Диаграммы классов и объектов используются для документирования ло¬ 
гических решений проекта системы. Здесь же мы будем рассматривать нота¬ 
цию для документирования физической реализации проекта, состоящей из 
программных и аппаратных средств. 

Модульная диаграмма определяет распределение классов и объектов в 
модулях, физически реализующих проект. Одна модульная диаграмма пред¬ 
ставляет всю или часть модульной архитектуры системы. (Многие авторы 
пользуются названиями Boochgrams и Gradygram, но мы будем использовать 
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термин «модульная диаграмма»). Как уже говорилось в гл. 2, некоторые 
объектно-базовые и объектно-ориентированные языки поддерживают своими 
средствами концепцию модульности и отличают термин «модуль» от терми¬ 
нов «класс» и «объект*. Концепция модульности может быть простой, напри¬ 
мер в C++ раздельная компиляция файлов, или более сложной, например 
пакетирование в Ada. Но в любом случае перед разработчиком стоит задача 
распределения классов, объектов, утилит по отдельным модулям. Языки, ко¬ 
торые не поддерживают явно модульную архитектуру, не требуют модульной 
диаграммы. Два важных элемента модульной архитектуры системы — моду¬ 
ли и видимость модуля. 



Рис. 5-17. Шаблон для объектов и сообщений. 

Модули. На рис. 5-19 показаны обозначения для различных видов мо¬ 
дулей. Эти обозначения имеют достаточно общий вид для эффективного ис¬ 
пользования их при любых объектно-базированных и объектно-ориентирован¬ 
ных языках, но для конкретного языка может быть пригодна только часть 
этих обозначений. Ada поддерживает все модули, показанные на рис. 5-19, 
Object Pascal и C++ — только отдельно компилированные файлы, эквивален¬ 
тные пакету. Каждый модуль имеет свое имя, которое записывается над 
обозначением модуля. Имя каждого модуля должно быть уникальным в пре¬ 
делах своей подсистемы. Имя, обведенное прямоугольником, обозначает мо¬ 
дуль, экспортируемый подсистемой, а подчеркнутое имя обозначает импорти¬ 
руемый модуль. Вложенность модулей обозначается вложенностью обозначе¬ 
ний модулей. 


Объект R 
Объект S 
Объект Т 
Объект U 


Рис. 5-18. Обозначения временной диаграммы. 
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Рис. 5-19. Обозначения модулей и видимости модулей. 

Обратите внимание на обозначение главной программы. Каждый проект 
должен иметь по крайней мере один головной модуль, из которой активизи¬ 
руется вся программа. Программный продукт, который выполняется на не¬ 
скольких компьютерах, связанных сетью, может иметь несколько главных 
программ. 

Видимость модулей. Единственная зависимость между модулями систе¬ 
мы — это компиляционная зависимость. На рис. 5-19 компиляционная зави¬ 
симость обозначается стрелкой. Чтобы показать, что модуль G зависит от 
модуля Н (в терминах C++G включает в себя Н), мы проводим стрелку от 
G к Н, тем самым обозначая, что Н видим для G. Мы можем дать имя 
этой стрелки, чтобы более полно документировать существующую связь. Ус¬ 
тановление таких связей позволяет определить порядок трансляции для Unix 
make tools и правильно откомпоновать программу. 

Пример модульной диаграммы. На рис. 5-20 представлена модульная 
диаграмма физической реализации тепличного хозяйства на основе гидропо¬ 
ники. На диаграмме представлены шесть модулей: два из них импортирова¬ 
ны извне, один экспортирован. Отметьте, что обозначение модулей состоит 
из двух частей: обозначение спецификации пакета (вверху) и обозначение 
тела пакета. Эта модульная диаграмма представляет достаточно типичную 
структуру проекта: импортируются ресурсы, необходимые для реализации, и 
экспортируется пакет, реализующий интерфейс. 

Классы Heater, Cooler и Lights помещены в импортируемом пакете 
GreenhouseActuators. Класс EnvironmentalController и его утилиты находятся 
в локальном модуле EnvironmentalControllers. 

Подсистемы 

Как было показано в гл. 2, большие системы можно разложить на сот¬ 
ни модулей. Но такую систему трудно понять. Поэтому разработчики пыта¬ 
ются объединить отдельные модули в какие-то группы. Ниже мы представим 
обозначения для модульных подсистем, аналогичные обозначениям категорий 
классов. Подсистема представляет собой набор логически связанных модулей 
и является полезным орудием при проектировании больших систем. 
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GreenhouseSensors GreenhouseActuaton 



Рис. 5-20. Модульная диаграмма тепличного хозяйства на основе 
гидропоники. 

К сожалению, большинство языков не поддерживает концепцию подси¬ 
стем; создание подсистем не одно и то же, что создание вложенных моду¬ 
лей. Поэтому мы утверждаем, что язык, даже такай сложный, как Ada, не 
является достаточным для полной реализации подсистем; пакетирование — 
необходимое средство декомпозиции, но отнюдь не достаточное. К счастью, 
многие программные средства позволяют работать с группами модулей. 
Целью создания подсистем является возможность документирования решений 
относительно видимости модулей в подсистеме. 

Обычно большая система имеет одну высокоуровневую модульную диаг¬ 
рамму, состоящую из подсистем самого высокого уровня абстракции. С по¬ 
мощью такой диаграммы разработчик может понять физическую структуру 
всей системы. Каждая подсистема является некоторой модульной диаграммой. 
Модульная диаграмма может содержать или только модули, или только под¬ 
системы. 

Обозначение подсистем. Обозначение подсистемы представлено на 
рис. 5-21. Правила именования подсистем и прикрепленные знаки, такие 
же, как и для имен модулей. Подсистемы связаны друг с другом компиля- 
ционной зависимостью, поэтому обозначение компиляционной зависимости 
применимо к подсистемам. 

Диаграмма подсистем почти аналогична диаграмме классов, представлен¬ 
ной на уровне категорий классов. Мы говорим «почти», поскольку есть раз¬ 
личия в типах иерархий, характерных для этих двух структур. Категории 
классов расположены по иерархии типа «разновидность», подсистемы распо¬ 
ложены в иерархии типа «составная часть», поскольку подсистемы строятся 
из нескольких подсистем нижнего уровня. 

Пример подсистемы. На рис. 5-22 представлена модульная диаграмма 
тепличного хозяйства на основе гидропоники. На ней представлены четыре 
подсистемы. Классы категорий Actuators, Sensors, 1РС (на рис. 5-7) пред- 
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ставлены в подсистеме GardeningSystemDevices. Классы, ассоциированные с 
категорией GreenhouseController, включены в подсистему 

GardeningSystemController; классы остальных двух категорий распределены 
между подсистемами GardeningSystemPlanner и GardeningSystemPlanDatabase. 

Шаблон модульной диаграммы 

Шаблон статического описания модуля. Графически представленная 
модульная диаграмма позволяет легко понять модульную структуру проекти¬ 
руемой системы. Для более полной документации еще рассмотрим шаблон 
модуля, показанный на рис. 5-23. 

Наиболее важным пунктом шаблона является список деклараций объек¬ 
тов, содержащихся в этом модуле. Список может включать классы, объекты, 
утилиты и другие специфичные для языка реализации объекты. Практически 
оказывается вполне достаточным показать на модульной диаграмме распреде¬ 
ление основных классов и объектов, оставив менее значительные объекты 
без внимания. Напомним, что нотация проекта преднамеренно опускает все 
незначительные детали. 

Возможно, что имя модуля в диаграмме модулей может отличаться от 
имени файла этого модуля. Например, в CLOS имя пакета совпадает с име¬ 
нем файла, в котором он хранится, но в Object Pascal возможна ситуация, 
когда пакет UDialogs хранится в файле UDiag.p. Если есть необходимость 
проследить местонахождение модулей в файлах, то шаблон модуля можно 
дополнить пунктом, содержащим имя файла. 

CD 

Рис. 5-21. Обозначение подсистем. 



Рис. 5-22. Модульная диаграмма тепличного хозяйства на основе гид¬ 
ропоники. 
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Рис. 5-23. Шаблон модуля. 

Шаблон динамического описания модуля. Многие рассмотренные выше 
диаграммы имели статическую и динамическую семантику. Разумно было бы 
считать, что модульная диаграмма является статическим описанием проекта. 
Тем не менее в некоторых применениях модули могут иметь и динамиче¬ 
скую семантику. Например, в случае малых ресурсов памяти разработчики 
должны предусмотреть возможность копирования модулей с использованием 
оверлейной техники программирования. Динамическую семантику модуля мы 
можем описать с помощью временных диаграмм или средствами PDL. 

5.7. ДИАГРАММЫ ПРОЦЕССОВ 
Процессоры и приборы 

Структура процессов. В гл. 2 мы уже говорили, что очень большая си¬ 
стема может потребовать программного обеспечения, состоящего из многих 
обособленных программ, выполненных на различных компьютерах. Для ре¬ 
шения задачи распределения аппаратных ресурсов мы будем пользоваться 
новым типом диаграмм — диаграммой процессов, которая содержит всю или 
часть процессорной архитектуры системы. Обычно проект включает одну ди¬ 
аграмму процессов, но для сложной системы их может быть несколько. Ди¬ 
аграмма процессов полезна и в случае однопроцессорной реализации проек¬ 
та, особенно если в проект вовлечены другие активные приборы и возможно 
существование параллельных процессов. 

Три наиболее важных элемента процессорной архитектуры — процессо¬ 
ры, приборы и соединения. Под процессором мы понимаем часть аппаратно¬ 
го обеспечения, которая может выполнять программу; приборы не обладают 
такой возможностью. 

Процессоры и приборы. На рис. 5-24 показаны обозначения процессо¬ 
ров и приборов. Правила именования процессоров и приборов те же, что и 
для модулей. Обозначения на рисунке стандартные, но нет причин ограни¬ 
чиваться только такими обозначениями. В любом случае обозначения долж¬ 
ны содержать в себе признаки, обозначающие процессор и прибор. Напри¬ 
мер, мы можем определить обозначения однокристального процессора, диско¬ 
вода, терминала, АЦП и затем использовать их в диаграмме процессов. Ди¬ 
аграмма процессов, таким образом, будет описывать физические средства 
проекта. 



Рис. 5-24. Обозначения процессоров, приборов и соединений. 
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Рис. 5-25. Диаграмма процессов тепличного хозяйства на основе 
гидропоники. 

Под каждым обозначением процессора можно проставлять имена про¬ 
грамм и процессов, выполняющихся на этом процессоре, и способы их дис¬ 
петчеризации. Обозначения диспетчеризации мы вскоре разработаем. 

Соединение процессоров и приборов 

Соединения. Процессоры и приборы должны взаимодействовать друг с 
другом. Используя линию, показанную на рис. 5-24, мы можем соединять 
приборы и процессоры, процессоры и процессоры, приборы и приборы. 
Обычно соединения представляют собой некоторый кабель (например, линия 
RS 232, Ethernet сеть, волоконно-оптический кабель), хотя они могут 
обозначать и не такую прямую связь (например, спутниковую). 

Соединения — обычно двунаправленные; для однонаправленного соеди¬ 
нения линия, его обозначающая, может иметь стрелку. Для полной доку¬ 
ментации линия, обозначающая связь, должна иметь метку. 

Пример диаграммы процессов. На рис. 5-25 представлен пример диаг¬ 
раммы процессов для тепличного хозяйства на основе гидропоники. Надо от¬ 
метить, что система содержит несколько компьютеров — один центральный 
компьютер и по одному для оранжерей (GreenHouse). Программы, выполня¬ 
емые в оранжереях, не могут взаимодействовать между собой непосредствен¬ 
но; такое взаимодействие обеспечивает центральный процессор. Для простоты 
мы решили не показывать приборы данной системы. 

Шаблон диаграммы процессов 

Диаграмма процессов позволяет увидеть физическую реализацию проек¬ 
та. Шаблон диаграммы процессов содержит дополнительную информацию о 
процессорах, приборах и соединениях. 
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Рис. 5-26. Шаблоны для процессоров, процессов, приборов и соединений. 

Шаблоны для процессоров и процессов. На рис. 5-26 представлены 
шаблоны для процессоров и процессов. В шаблон процессора мы можем 
записать характеристики компьютера (завод-изготовитель, номер, объем па¬ 
мяти). Более важным является пункт, определяющий процесс; выполняемый 
на данном процессоре процесс может представлять собой головной модуль 
(описанную в модульной диаграмме) или активный объект (определенный в 
диаграмме классов или объектов). Шаблон имеет пункт, определяющий ка¬ 
нал управления, и его приоритет (если такой имеется). Если система про¬ 
ста, то мы имеем всего лишь один процесс (головной модуль); более слож¬ 
ные системы имеют несколько активных процессов. Возможно, далеко не все 
из них активны одновременно, тем не менее мы должны предусмотреть са¬ 
мые худшие варианты. Необходимо определить оптимальный график загруз¬ 
ки процессоров, чтобы избежать возможности тупиковой ситуации. 

Диспетчеризация процессов. Мы должны некотором образом определить 
порядок выполнения процессов на одном процессоре. Ниже приведены пять 
способов подобной диспетчеризации. Шаблон процессора должен содержать 
один из этих способов. 


Приоритетный 


Неприоритетный 

Циклический 


Управляющая 

программа 

Ручной 


Процесс с более высоким приоритетом выгружает про¬ 
цесс с меньшим приоритетом; процессы с одинаковым 
приоритетом выполняются процессором в течение не¬ 
большого кванта времени, затем загружается следующий 
процесс, и таким образом все процессы равноправно ис¬ 
пользуют ресурсы процессора 

Текущий процесс выполняется на процессоре до тех 
пор, пока он сам не уступит контроль над процессором 
Контроль управления переходит от одного процесса к 
другому, каждый процесс имеет для выполнения неболь¬ 
шой промежуток времени — фрейм 
Конкретный алгоритм управляет загрузкой процессов 

Процессы запускаются пользователем, например с кла¬ 
виатуры 


Для более полного описания диспетчеризации можно включить в шаб¬ 
лон временную диаграмму или фрагменты PDL. Временная диаграмма и 
PDL будут полезны для описания динамического поведения программ и объ¬ 
ектов, которые могут мигрировать от процессора к процессору. 

Шаблон соединений. На рис. 5-26 показан шаблон для соединений. 
Для программистов шаблон соединений имеет второстепенное значение, хотя 
для пользователей системы он может быть полезен. 
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5.8. ПРИМЕНЕНИЕ СИСТЕМЫ ОБОЗНАЧЕНИЙ 
Продукты объектно-ориентированного проектирования 

В этой главе описаны основные продукты объектно-ориентированного 
программирования. Обычно проект включает ряд диаграмм классов, объектов, 
модульных диаграмм, диаграмм процессов. Самый абстрактный уровень опи¬ 
сания проекта делится на три части: диаграмма классов проекта с самым 
высоким уровнем абстракции (определяет основные абстракции логической 
части проекта), модульная диаграмма (показывает основные моменты про¬ 
граммной реализации проекта) и диаграмма процессов (показывает ключевые 
моменты физической реализации проекта). Основные механизмы взаимодей¬ 
ствия показаны на различных диаграммах объектов. 

Все диаграммы взаимосвязаны друг с другом, что позволяет проследить 
связь между реализацией проекта и его спецификацией. На диаграмме про¬ 
цессов может быть обозначена главная программа, которая определена в не¬ 
которой модульной диаграмме. Модульная диаграмма в свою очередь 
содержит описание набора классов и объектов; описания каждого из классов 
или объектов из этого набора можно найти на соответствующих диаграммах 
классов и объектов. 

Система обозначений, описанная выше, может быть использована при 
ручной документации проекта; для больших проектов, очевидно, хотелось бы 
иметь автоматическую поддержку. Автоматическая система помощи могла бы 
проводить проверку на корректность и полноту документации, помогла бы 
разработчику легко и быстро просматривать проектную документацию. Глядя 
на модульную диаграмму, разработчик, возможно, захочет рассмотреть неко¬ 
торые механизмы взаимодействия — автоматическая система определит и 
покажет соответствующий объект. Для каждого объекта из диаграммы объек¬ 
тов автоматическая система документации сможет показать спецификацию 
соответствующего класса этого объекта и также показать место этого класса 
в иерархической структуре классов. Если объект является активным, автома¬ 
тическая система поможет определить процессор этого объекта. Автоматиче¬ 
ская система избавит разработчика от рутинной работы, от необходимости 
помнить множество незначительных деталей, тем самым помогая ему сосре¬ 
доточиться на творческой части работы. 

Описанная система обозначений применима как для небольших систем, 
так и для больших. В гл. 6 и 7 показано, что эта система обозначений 
очень удобна при последовательном итеративном подходе к процессу проек¬ 
тирования. Нет необходимости считать диаграммы завершенной работой, ско¬ 
рее всего диаграммы эволюционируют в процессе проекта и документируют 
новые проектные решения. 

Мы также нашли нашу систему обозначений, не зависящей от языка 
реализации. Поэтому она применима для всех объектно-базовых и объектно- 
ориентированных языков. 

До сих пор мы говорили о синтаксисе и семантике графической нота¬ 
ции. В следующих двух главах мы рассмотрим процесс объектно-ориентиро¬ 
ванного проектирования. Все эти обсуждения будут заканчиваться демонстра¬ 
цией пяти примеров объектно-ориентированного проектирования. 
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Заключение 

* Проектирование не заключается в рисовании диаграмм: диаграммы описы¬ 
вают существенные детали проекта. 

* При проектировании сложных систем очень важно иметь возможность 
смотреть на проект с различных точек зрения (логическая и физическая 
структура, статическая и динамическая семантика). 

* Система обозначений объектно-ориентированного проекта включает четыре 
базовые диаграммы (диаграмма классов, диаграмма объектов, модульная 
диаграмма и диаграмма процессов) и две вспомогательные (диаграмма пе¬ 
реходов и временная диаграмма). 

* Диаграмма классов определяет существующие классы и их связь в логиче¬ 
ском проекте системы; диаграмма классов представляет все или часть 
классов проекта. 

* Диаграмма объектов определяет объекты и их взаимодействие в логиче¬ 
ском проекте системы; диаграмма объектов представляет все или часть 
объектов системы и иллюстрирует основные механизмы взаимодействия. 
Диаграмма объектов представляет собой фотографию событий или конфи¬ 
гурации системы. 

* Модульная диаграмма определяет распределение классов и объектов в мо¬ 
дулях программной реализации системы; модульная диаграмма показывает 
всю или часть модульной архитектуры системы. 

* Диаграмма процессов определяет распределение процессов между процессо¬ 
рами физической реализацией системы; диаграмма процессов показывает 
всю или часть процессорной архитектуры системы. 

* Диаграмма переходов определяет пространство состояний экземпляров кон¬ 
кретного класса, события, приводящие к переходам из одного состояния в 
другое, и результаты такого перехода. 

* Временная диаграмма определяет динамическое взаимодействие между объ¬ 
ектами. 

Дополнительная литература 

Книга Martin и McClure [Н, 1988 ] — основной справочник по различ¬ 
ным системами обозначений. 

Ранние версии нотации появились в книге Booch [F, 1981]. В дальней¬ 
шем были заимствованы элементы семантических сетей (Stillings et al. 
[А, 1987], Barr и FeigenBaum [J, 1981]), теории моделей (Ross [F, 1987]) 
и сетей Petri (Peterson [J, 1977], Saharaoui [F, 1987], Bruon and Balsamo 
[F, 1986]). Обозначения для объектов и пакетов были частично заимствова¬ 
ны из работ Intel над iARX 432 [D, 1981 ]. Обозначения для диаграммы 
объектов взяты из работ Seidewitz [F, 1985]. Обозначения параллельных се¬ 
мантик заимствованы из работ Buhz |F, 1988, 1989]. Диаграммы переход¬ 
ных процессов развиты из работ Hard [F, 1987,1988]. 

Другие способы документирования объектно-ориентированного проекта 
описаны в работах Fischer [С, 1987], Kelly [F, 1986], Grosch [F, 1983], 
Cunningham и Beck [F, 1986], Kleyn и Gringrich [K, 1988], Schwan и 
Mattlnws [K, 1986]. 



Глава 6 


Процесс 

Начинающий программист всегда старается найти такое волшебное сред¬ 
ство, эпохальное технологическое новшество, которое мгновенно упростит 
процесс создания программ. Программист-профессионал знает, что подобного 
средства нет и не может быть. Новичкам хочется следовать известным ре¬ 
цептам; профессионалы же знают, что любой жесткий подход приведет к 
созданию почти бесполезного продукта. Наконец, когда программист-новичок 
начинает составлять документацию на свою разработку, он заботится прежде 
всего о том, как она будет выглядеть для покупателя, а не о том, какую 
информацию можно в ней найти. Профессионал же понимает всю важность 
документации, но никогда для него требования к форме продукта не будут 
определять процесс его создания. 

Процесс объектно-ориентированного проектирования — полная противо¬ 
положность жесткому подходу. Он представляет собой поступательный итера¬ 
тивный процесс, результаты которого оформляются постепенно в процессе 
разработки. 

6.1. ПРОЕКТИРОВАНИЕ КАК ПОСТУПАТЕЛЬНЫЙ 
ИТЕРАТИВНЫЙ ПРОЦЕСС 
Возвратное проектирование 

Каким должно быть проектирование: сверху вниз или снизу вверх? 
Этот вопрос с религиозным рвением часто обсуждался в среде специалистов 
по программному обеспечению. Нисколько не умаляя знаний программистов, 
следует признать, что специалисты по аппаратным средствам имеют боль¬ 
ший опыт в этой области, поэтому мы задали этот вопрос Дрюку — архи¬ 
тектору компьютерных систем и проектировщику СБИС [1]. Его ответ стал 
для нас откровением. Предположим, что требуется набрать людей в органи¬ 
зацию, занимающуюся разработкой и наладкой достаточно сложных 
аппаратных средств. Можно использовать горизонтальный набор, когда в 
увеличивающейся прогрессии нам придется нанимать специалистов по каж¬ 
дой из подсистем (начиная с архитекторов системы), затем специалистов по 
логическому проектированию, конструкторов схем и т.д. Это пример проек¬ 
тирования сверху вниз, когда мы приглашаем специалистов, которых Дрюк 
называет «высокими худыми людьми», потому что каждый из них обладает 
узкими и глубокими знаниями в своей области. Можно пойти по другому 
пути и нанять проектировщиков -- «специалистов на все руки*, которые бо¬ 
лее менее представляют себе весь проект от начала до конца — от архи¬ 
тектурных концепций до отдельных схем. Дрюк называет таких специали¬ 
стов «короткими толстыми людьми». Нередко, к сожалению, из-за сложности 
задачи разработки программного обеспечения нам приходится искать специа¬ 
листов, которых можно назвать «высокими толстыми людьми*. 

Опыт подсказывает, что проектирование не может осуществляться 
только сверху вниз или только снизу вверх. Дрюк считает, что хорошо 
структурированные сложные системы можно создать методом «возвратного 
проектирования». В этом методе основное внимание уделяется процессу по- 
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ступательного и итеративного развития путем совершенствования различных, 
но тем не менее совместимых между собой логических и физических 
моделей системы. Мы считаем, что возвратное проектирование составляет ос¬ 
нову процесса объектно-ориентированного проектирования. 

Людям, формально обученным методам структурного проектирования, 
процесс объектно-ориентированного проектирования может показаться слиш¬ 
ком произвольным и нечетким. Мы этого не отрицаем, но должны также 
заметить, что никому еще не удалось организовать творческий процесс, жес¬ 
тко определив все возможные варианты действий. Конечно, чем больше мы 
знаем о проблеме, которую предстоит решить, тем легче ее решить. Если, 
например, вы только что возвели один дом своими руками, построить вто¬ 
рой вам будет значительно легче, потому что вы знаете, что надо делать и 
в какой последовательности. Аналогичная ситуация возникает и при разра¬ 
ботке программ. Действительно, отчасти это является причиной довольно вы¬ 
сокой производительности труда, о которой так любят распространяться не¬ 
которые «фабрики» программных средств [2]. В таких организациях решае¬ 
мая задача обычно хорошо определена (например, обработка платежных ве¬ 
домостей), и под нее уже созданы механизмы решения. В этих областях 
процесс проектирования почти полностью систематизирован и разработчики 
новой системы уже знают наиболее важные абстракции, механизмы, которые 
необходимо применить, и в основном представляют себе поведение будущей 
системы. Подобная ситуация предполагает возможность повторного использо¬ 
вания не только отдельных программных компонент, но и самого метода 
вместе с требованиями к системе. Элемент творчества имеет важное значе¬ 
ние и в такого рода разработках, но он находит здесь ограниченное приме¬ 
нение, так как основные проблемы проектирования системы уже решены. 
Производительность в результате оказывается неестественно высокой по 
сравнению с уникальными разработками. 

Эксперименты Картиса и его коллег [3 ] подтверждают эти наблюдения. 
Картис изучал работу профессиональных разработчиков программного обеспе¬ 
чения, фиксируя видеокамерой их действия и затем анализируя их содержа¬ 
ние (анализ, проектирование, ввод данных и т.д.) и время, затрачиваемое 
на их выполнение. В результате этих исследований он сделал вывод о том, 
что «создание программ представляет собой, по-видимому, ряд взаимопересе- 
кающихся итеративных и беспорядочных процессов, проходящих под непос¬ 
ледовательным контролем... Сбалансированный процесс разработки сверху 
вниз оказывается, по-видимому, особым случаем, соответствующим абсолют¬ 
но правильно выбранной схеме решения или простой задаче... Хорошие раз¬ 
работчики одновременно могут охватить многие уровни абстракции и рабо¬ 
тать в них». 

Как уже говорилось в гл. 1, большинство программных систем достаточ¬ 
но уникально и их разработчики имеют, следовательно, весьма ограничен¬ 
ный опыт. В таких условиях полезно в процессе разработки периодически 
анализировать полученные результаты, совершенствовать промежуточный 
продукт в соответствии с новыми представлениями и повторять этот про¬ 
цесс, пока проект не будет корректным образом полностью реализован. Хай- 
нляйн предлагает в том случае, «когда вы имеете дело с непонятной зада¬ 
чей, решить ту ее часть, которая вам понятна, а потом вернуться к про¬ 
блеме снова» [4]. Это еще одно определение понятия «возвратное проекти¬ 
рование». 
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Объектно-ориентированное проектирование: действия 
и результаты 

Процесс объектно-ориентированного проектирования является возвратным 
процессом; модели проектирования, рассмотренные в гл.5, являются продук¬ 
тами данного процесса. Объединение понятий объектно-ориентированного и 
возвратного проектирования дает нам большие потенциальные преимущества. 
Богатая система нотаций позволяет, например, моделировать задачу несколь¬ 
кими возможными путями и фокусировать внимание в разное время на от¬ 
носительно независимых частях проблемы. Эволюционный характер процесса 
проектирования дает возможность использовать ту модель, которая в 
настоящий момент наиболее нужна для решения поставленной задачи. Мы 
могли бы, например, сначала составить схему структуры классов системы с 
помощью диаграмм классов, затем разработать некоторые механизмы, ис¬ 
пользующие эти абстракции, и задокументировать их в серии объектных ди¬ 
аграмм. Проектируя детали этих механизмов, мы возвращаемся обратно к 
структуре классов, устанавливаем протоколы для каждого класса и, возмож¬ 
но, реорганизуем порядок наследования, чтобы лучше использовать 
принятую общность выразительных средств. По окончании процесса проекти¬ 
рования мы получаем ряд диаграмм, соответствующих различным, но при 
этом четким и согласующимся моделям системы, появившимся в результате 
эволюции предыдущих устойчивых, хотя и не столь подробных моделей. 

Ступенчатый, итеративный процесс объектно-ориентированного проекти¬ 
рования отличается от традиционного процесса разработки программного 
обеспечения, где приходится мириться с лавинообразным нарастанием слож¬ 
ности в процессе создания программ. Если говорить откровенно, надо при¬ 
знать, что традиционный подход имеет ряд неустранимых недостатков и 
нарушает многие инженерные принципы. И дело не только в том, что 
процесс проектирования ни в коем случае не должен быть жестко структу¬ 
рирован. Кроме этого, он обязательно должен предполагать эволюционность 
развития. Подобный подход соответствует спиральной модели развития про¬ 
граммного обеспечения, которая предложена Бемом и «выдвигает на первый 
план подход к развитию программного обеспечения, ориентированный преж¬ 
де всего на риск, а не на прототипы и спецификации» [5]. 

Объектно-ориентированное проектирование это не тот процесс, который 
начинается с определения требований, завершается составлением схемы при¬ 
менения системы, а между этими двумя событиями представляет собой 
нечто непонятное и таинственное. В соответствии с нашими представлениями 
процессу объектно-ориентированного проектирования соответствует примерно 
следующий порядок событий: 

* Идентификация классов и объектов данного уровня абстракции. 

* Идентификация семантики классов и объектов. 

* Идентификация связей между классами и объектами. 

* Использование классов и объектов. 

Это постепенный процесс: идентификация новых классов и объектов 
обычно заставляет нас модифицировать семантику и связи между существен¬ 
ными классами и объектами. В то же время это итеративный процесс: ис¬ 
пользование классов и объектов часто приводит к необходимости разработки 
и создания новых классов и объектов, присутствие которых упрощает про¬ 
цесс проектирования. 
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С чего начать процесс объектно-ориентированного проектирования и чем 
его завершить? Начинать надо с создания классов и объектов, формирующих 
словарь проблемной области. Конечной целью является «идентификация всех 
объектов, принадлежащих проблемной области и играющих заметную роль, 
определение связей между объектами и наделение каждого объекта опреде¬ 
ленными функциями, с помощью которых он будет совершать действия над 
другими объектами и другие объекты будут совершать действия над ним, а 
также анализ этих функций на том уровне, который больше всего подходит 
для их понимания» [6]. Таким образом, мы можем остановить процесс про¬ 
ектирования, если увидим, что больше нет ключевых абстракций и механиз¬ 
мов, не включенных в нашу модель, и используя уже существующие ком¬ 
поненты программного обеспечения, применяя их к созданным классам и 
объектам, мы можем обеспечить требуемое поведение нашей системы. В 
этом случае не имеет смысла проектировать что-то новое; главной задачей 
становится применение созданных нами моделей. 

Ниже мы подробнее рассмотрим каждый из четырех шагов процесса 
проектирования и их результаты. В гл. 7 мы приведем некоторые примеры 
таких процессов и проанализируем их в основном с точки зрения руководи¬ 
телей, обязанных управлять ходом работ и использовать объектно-ориентиро¬ 
ванное проектирование, так как этот процесс требует знания ряда основных 
положений и предполагает совершенно другой подход к распределению ре¬ 
сурсов и к управлению, чем для традиционных процессов. В гл. 8-12 рас¬ 
смотрен широкий спектр различных объектных и объектно-ориентированных 
языков программирования. 

6.2. ИДЕНТИФИКАЦИЯ КЛАССОВ И ОБЪЕКТОВ 
Действия 

Первый шаг состоит из двух действий: создание основных абстракций, 
принадлежащих проблемной области (важнейших классов и объектов), и 
разработка основных механизмов, обеспечивающих требуемое поведение объ¬ 
ектов, которые в свою очередь обеспечивают функционирование системы. 
Каким образом мы выделяем эти абстракции и механизмы? Анализируя 
конкретную предметную область с помощью методов, описанных в гл. 4, 
разработчик при этом должен действовать по существу как абстракционист. 
Изучая требования к задаче и (или) обсуждая их в процессе дискуссий со 
специалистами по данной проблеме, разработчику необходимо освоить терми¬ 
нологию проблемной области, основные теоретические положения, их роль. 
Затем приблизительно сформировать классы и объекты вплоть до самого вы¬ 
сокого уровня абстракции. 

Следует отметить, что пока это лишь классы и объекты «в начальном 
приближении», ведь на данном этапе разработки мы только приступаем к 
определению границ для наших абстракции. Мы предполагаем, что эти гра¬ 
ницы будут видоизменяться с течением времени в процессе того, как мы 
начнем обнаруживать что-то общее у наших классов и объектов и мо¬ 
дифицировать введенные нами механизмы взаимодействия. Хотя их внешний 
вид может слегка изменяться, обычно оказывается, что и классы, и объек¬ 
ты, определенные на ранних стадиях проектирования, сохраняются на протя¬ 
жении всего процесса создания системы. Этого можно было ожидать, так 
как соответствие продуктов объектно-ориентированного проектирования ре¬ 
альной физической модели является одним из принципов создания объектной 
модели. 
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Рассмотрим проект гидропонно-садовой системы. Даже поверхностное оз¬ 
накомление с требованиями к системе позволит определить ее основные 
компоненты: растущие растения, сельскохозяйственные культуры и окружаю¬ 
щие их параметры среды (например, температура воздуха и концентрация 
питательных веществ). Данные абстракции существенны для рассматриваемой 
предметной области и, таким образом, входят в первоначальный список 
классов и объектов проекта решения нашей задачи. 

Результаты 

Результаты первого шага могут быть различными: иногда достаточно 
лишь составить список имен важнейших классов и объектов, так чтобы эти 
имена несли определенную смысловую нагрузку в соответствии с местом и 
функциями того или иного объекта или класса в вашей системе. Мы назы¬ 
ваем это «списком имен», который всегда открыт для продолжения [7]. Од¬ 
ни элементы данного списка могут оказаться классами, другие — объектами, 
а третьи — свойствами объектов. Результатом первого шага может стать не 
просто определение имен, но также заполнение шаблонов соответствующих 
классов и объектов, т.е. формальное определение смысла выделенных 
абстракций и механизмов. 

В большинстве случаев этот шаг занимает немного времени по сравне¬ 
нию с остальными тремя шагами. Нередко руководитель проекта в одиночку 
составляет предварительный список классов и объектов, а затем обсуждает 
этот список с коллегами, проводя своего рода проверку умственных способ¬ 
ностей подчиненных. Основная цель составления такого списка заключается 
в выработке терминологии общения между разработчиками. Проектировщику 
также может оказаться полезно начертить кое-какие диаграммы классов или 
объектов, чтобы уяснить механизмы совместного их функционирования. Если 
вдруг важное значение приобретает проблема физической декомпозиции сис¬ 
темы, параллельно можно начертить модульные диаграммы. Если же в сис¬ 
теме присутствуют элементы аппаратного обеспечения, полезно составить не¬ 
обходимые диаграммы процессов. 

6.3. ИДЕНТИФИКАЦИЯ СЕМАНТИКИ КЛАССОВ И 

ОБЪЕКТОВ 

Действия 

Второй шаг — основной — заключается в определении содержания 
классов и объектов, заданных на предыдущем шаге. Здесь разработчик дей¬ 
ствует как бы со стороны, анализируя каждый класс с точки зрения перс¬ 
пективы его взаимодействия с другими классами и объектами и определяя 
механизмы взаимодействия классов и объектов. 

Этот шаг гораздо труднее первого и занимает больше времени: не 
обойдется без жарких дебатов, выкриков, зубовного скрежета и упоминаний 
личных имен на совещаниях. Классы и объекты определить легко, догово¬ 
риться о содержании протокола для каждого объекта гораздо сложнее. По 
этой причине с определенного момента процесс объектно-ориентированного 
проектирования становится итеративным. Составление протокола для данного 
объекта может потребовать принятия решений, затрагивающих содержание 
другого объекта. При этом само существование наших абстракций не ставит¬ 
ся под вопрос, происходит лишь смещение границ между ними. Для того 
чтобы направить данную деятельность в нужное русло, полезно составить 
12 Гради Буч 
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для каждого объекта свой текст, который определял бы цикл его функцио¬ 
нирования — от создания до удаления и особенности его поведения. 

Проектируя, например, гидропонно-садовую систему тепличного 
хозяйства, нам необходимо сначала создать класс, экземпляры которого 
представляют собой выращиваемые растения. Можно так спроектировать этот 
класс, что его объекты будут содержать знания о всех подробностях процес¬ 
са выращивания данной сельскохозяйственной культуры, включая знания о 
том, как составить план такого выращивания. Позднее нам может показать¬ 
ся, что протокол этого класса слишком перегружен, и мы тогда создадим 
другой класс — менеджер планов выращивания, который знает, как обеспе¬ 
чивать выполнение планов, являющихся частью состояния объектов. Подо¬ 
бные эволюционистские решения приводят к созданию новых классов и ме¬ 
няют внешний вид первоначальных. 

Результаты 

Результаты данного шага отражают ступенчатый характер процесса объ¬ 
ектно-ориентированного проектирования. Выработав конструкторские реше¬ 
ния, касающиеся содержания каждого класса и объекта, мы в основном за¬ 
вершим доводку шаблонов, созданных на первом шаге. Для этого 
необходимо наилучшим образом зафиксировать все статические и динамиче¬ 
ские свойства каждой основной абстракции и механизма. Мы могли бы так¬ 
же начертить новые диаграммы объектов, отражающие те механизмы, кото¬ 
рые были введены на данном этапе процесса. В заключение, мы могли бы 
создать прототипы отдельных частей проекта с целью анализа его текущего 
состояния и оценки различных подходов к решению тех подзадач, которые, 
по нашему мнению, находятся в зоне повышенного риска. 

6.4. ИДЕНТИФИКАЦИЯ СВЯЗЕЙ МЕЖДУ КЛАССАМИ 

И ОБЪЕКТАМИ 

Действия 

Третий шаг можно рассматривать как продолжение предыдущего. Здесь 
мы точнее определяем механизмы взаимодействий внутри системы. Что ка¬ 
сается основных абстракций, то мы должны определить типы отношений 
между ними: использование, наследование и т.д. Необходимо также 
определить статические и динамические свойства объектов и их механизмов. 

Существуют две основные причины, заставляющие нас заниматься со¬ 
вершенствованием результатов нашего проекта. Во-первых, мы должны раз¬ 
работать структуры: структуры классов, что приводит к необходимости реор¬ 
ганизации и упрощения системы классов, и структуры совместных организа¬ 
ций объектов, что ведет к обобщению механизмов взаимодействий, включен¬ 
ных в проект. На данном шаге проектирования от разработчика требуется 
мобилизация всех творческих сил; по степени успеха, достигнутого на 
данном шаге, ваш проект будет затем оцениваться как просто хороший или 
как чрезвычайно удачный. 

Во-вторых, мы должны определить границы видимости: какие классы и 
объекты могут видеть друг друга, и, что не менее важно, какие классы и 
объекты не могут видеть друг друга. Эти решения помогут нам затем пред¬ 
принять верные шаги при проектировании архитектуры модулей нашей сис¬ 
темы. Разработка структур и принятие решений о степени видимости могут 
также заставить нас провести усовершенствование протоколов для классов, 
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выделенных на более ранних этапах. В конце концов мы получим общие 
абстракции и механизмы, определенные только в одном месте. 

Метод, который, по-видимому, может помочь при подобных операциях, 
заключается в использовании карт КФС (класс, функции, связи), предло¬ 
женных Беком и Каннингемом [8]. Карта КФС — обычная карточка (по 
одной на каждый класс), на которой написано имя класса, функции, котЪ- 
рыми он наделен, и имена классов, с которыми он совместно функциониру¬ 
ет. Проектировщик может затем располагать эти карты на столе по своему 
усмотрению и редактировать их содержание в соответствии с описанием 
циклов функционирования объектов, составленных на предыдущем этапе. 

Рассмотрим еще раз проект гидропонно-садовой системы. 
Проанализировав уже разработанные механизмы, мы сможем заметить, что 
механизм записи информации об индивидуальных планах выращивания каж¬ 
дого растения можно применить для записи информации о пользователях 
редактора этих планов. Такая структура абстракций и механизмов может 
быть разработана только специалистом, использующим метод возвратного 
проектирования. Его применение предусматривает возможность создания од¬ 
ного, а не двух механизмов для поддержки сходного функционирования 
двух разных, не связанных между собой, частей системы. 

Следует отметить, что на данном шаге проекта мы все еще рассматри¬ 
ваем существующие абстракции и механизмы как бы со стороны. На первых 
трех шагах не стоит пытаться рассматривать их как часть нашей системы, 
потому что мы еще до конца не решили, как та или иная абстракция или 
тот или иной механизм конкретно будет использован. 

Результаты 

Результатом данного шага является завершение создания большинства 
логических моделей проекта. Происходит доводка диаграмм классов, разрабо¬ 
танных на предыдущих шагах, с учетом принятых решений о структурах 
классов и объектов и об их взаимной видимости. Мы окончательно заполня¬ 
ем диаграммы объектов, фиксирующие основные механизмы, которые при¬ 
сутствуют в нашей системе. Составление таких диаграмм на практике — 
дело довольно простое. Используя нотации из гл.5, мы сначала рисуем объ¬ 
екты, которые, как мы знаем, определенным образом взаимодействуют друг 
с другом. Затем мы выбираем пару объектов и определяем, взаимодействуют 
ли они друг с другом. Если ответ положителен, мы можем задать следую¬ 
щие два вопроса: каким образом эти объекты связаны, и какие сообщения 
передают они друг другу? Обычно после этого нам приходится изменять 
протоколы соответствующих классов, а эти изменения в свою очередь могут 
заставить нас создать некоторые дополнительные структуры. Именно поэтому 
мы и говорим, что объектно-ориентированное проектирование — итератив¬ 
ный процесс. 

С этого момента мы можем начинать создавать необходимые модульные 
диаграммы нашего решения (или редактировать старые), принимая во вни¬ 
мание те решения о взаимной видимости классов, что мы приняли ранее. 
Мы стараемся построить классы, объекты и модули, которым было бы 
проще взаимодействовать друг с другом. Теперь наш продукт находится на 
такой стадии разработки, когда мы можем оценить его с помощью тех кри¬ 
териев, о которых шла речь в гл. 3. После соответствующего анализа нам, 
возможно, придется изменить наш проект, чтобы улучшить свойства наших 
основных абстракций и механизмов. 
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На данном шаге мы также продолжаем разрабатывать прототипы. Мы 
можем создавать новые прототипы, чтобы еще раз сравнить различные под¬ 
ходы к проектированию тех элементов системы, которые, на наш взгляд, 
являются источником повышенного риска. Мы можем также редактировать 
старые прототипы с целью создания прототипов, обладающих большими 
функциональными возможностями, которые в конце концов станут частью 
конечной реализации нашей системы. Действуя по такой схеме, мы всегда 
будем иметь работающий вариант нашей системы. 

6.5. РЕАЛИЗАЦИЯ КЛАССОВ И ОБЪЕКТОВ 
Действия 

Четвертый шаг — не всегда последний. Предстоит решить еще две ос¬ 
новные задачи: принять решения относительно включения в нашу систему 
конкретных классов и объектов и распределить классы и объекты по отдель¬ 
ным модулям, а программы — по процессорам. На этом шаге проектирова¬ 
ния мы впервые рассматриваем каждый объект и класс изнутри, чтобы на¬ 
метить способы реализации его свойств. 

Но даже если наши абстракции и механизмы довольно просты, в этом 
месте обычно приходится возвращаться к первому шагу и снова проходить 
весь путь, рассматривая изнутри существующие классы и отдельные модули. 
Таким образом мы повторяем процесс проектирования, фокусируя внимание 
на более низких уровнях абстракции. Означает ли это, что объектно-ориен¬ 
тированное проектирование является примером проектирования сверху вниз? 
Не совсем. На практике мы сначала проектируем более высокие уровни абс¬ 
тракции и включаем в них те классы и объекты, которые явно соответству¬ 
ют терминологии предметной области. Однако, находясь на любом шаге 
разработки, нам часто приходится обращаться к более низким уровням абст¬ 
ракций и механизмов, так как они являются теми первичными классами и 
объектами, на основе которых построены все классы и объекты более высо¬ 
ких уровней. Таким образом, мы опять видим, что объектно-ориентирован¬ 
ное проектирование включает процесс возвратного проектирования. 

Результаты 

На данном шаге мы организуем конкретное взаимодействие между каж¬ 
дым классом и объектом, который играет какую-то роль на рассматриваемом 
уровне абстракции. Результатом, таким образом, является конечная доработ¬ 
ка структуры классов нашей системы, и, в частности, завершение процесса 
создания шаблонов для каждого класса. Такого же уровня полноты должны 
достигнуть модульные диаграммы и, если этого требует архитектура систе¬ 
мы, диаграммы процессов. 

Заключение 

* Процесс объектно-ориентированного проектирования нельзя определить ни 
как проектирование сверху вниз, ни как проектирование снизу вверх; его 
можно скорее назвать «возвратным проектированием», что подразумевает 
ступенчатый и итеративный процесс разработки системы с постепенной 
модификацией различных, но тем не менее согласованных между собой 
логических и физических представлений о системе в целом. 

* Процесс объектно-ориентированного проектирования начинается с разработ¬ 
ки классов и объектов, формирующих словарь предметной области; он за- 
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вершается, когда оказываются исчерпаны все базовые абстракции и меха¬ 
низмы или когда разработанные нами классы и объекты могут быть со¬ 
ставлены из уже существующих универсальных программных компонент. 

* Первый шаг процесса объектно-ориентированного проектирования включает 
идентификацию классов и объектов данного уровня абстракции; наиболее 
важной является разработка основных абстракций и механизмов. 

* Второй шаг заключается в определении свойств этих классов и объектов; 
здесь разработчику важно действовать как бы со стороны, рассматривая 
каждый класс с точки зрения взаимодействия его с другими классами. 

* Третий шаг заключается в определении связей между различными класса¬ 
ми и объектами; здесь мы устанавливаем, каким образом происходят вза¬ 
имодействия внутри системы, обращая при этом внимание на статические 
и динамические свойства основных абстракций и механизмов. 

* Четвертый шаг представляет собой процесс создания классов и объектов; 
наиболее важным является правильный выбор места в логической 
структуре системы для каждого класса и объекта, распределение классов и 
объектов по отдельным модулям, программам и процессам; этот шаг не 
обязательно является последним, так как для его завершения обычно тре¬ 
буется снова пройти весь процесс от начала до конца, на сей раз 
обращая основное внимание на более низкие уровни абстракции. 

Дополнительная литература 

Существует несколько вариантов организации процесса объектно-ориен¬ 
тированного проектирования. Сравнение наиболее популярных подходов мож¬ 
но найти в работах Boehm-Davis and Ross [Н, 1984], Kelly [F, 1986], 
Mannino [F, 1987]. Обзор ряда других методов, включающих объектно-ори¬ 
ентированное проектирование, можно найти у Webster [F, 1988]. Первона¬ 
чальный вариант процесса, рассмотренного в этой главе, впервые описан 
Booch [F, 1982]. Berard позднее усовершенствовал данную методологию [F, 
1986]. Ряд аналогичных подходов рассмотрен в работах GOOD (General 
Object-Oriented Design) Seidewitz and Stark [F, 1985, 1986, 1987]; SOOD 
(Structured Object-Oriented Design) Lockheed [C, 1988]; MOOD (Multiple view 
Object-Oriented Design) Keth [F, 1988] и HOOD (Hierarchical Object-Oriented 
Design) CISI Ingenierie and Matra, for the European Space Station [F, 1987]. 
В работах Wasserman, Pirchcr и Muller [F, 1988], Mills ]H, 1986] и 
Constantine [F, 1989] рассматривается смешанный подход, включающий объ¬ 
ектно-ориентированное проектирование и структурный подход и названный, 
как и следовало ожидать, объектно-ориентированным структурным проекти¬ 
рованием (OOSD). Ряд других ученых предлагают похожие модели проекти¬ 
рования, и здесь мы можем привести достаточно большой список работ: 
Alabios [F, 1988], Boyd [F, 1987], Buhr [F, 1984], Cherry [F, 1987, 1990], 
Felsinger [F, 1987], Fivesmith [F, 1986], Hines и Unger [G, 1986], Jacobson 
[F, 1985], Jamsa [F, 1984], Kadie [F, 1986], Masiero и Gevmano [F, 1987], 
Nielsen [F, 1988], Nies [F, 1986], Rajlich и Silva [F, 1987], и Shumate [F, 
1987 ]. Основные шаги обьектно-ориетированного проектирования, рассмотрен¬ 
ные в этой главе, аналогичны предложенным в работах Ваіііп [В, 1988], 
Barry, Thomas, Altolf и Wilson [С, 1987], Chen ]F, 1976], Coad [В, 1989], 
Date [E, 1986], Goldbend и Kay [G, 1977], Gouda, Han, Jensen, Johnson, и 
Kain [F, 1977], Henderson [J, 1986], Jackson [H, 1983], Keene [G, 1989], 
Mascot [H, 1987], Pinson и Weiner [G, 19881, Smith и Smith [E, 1980] и 
Yourdon [H, 1989]. 
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Традиционные методы 

Разработка программного обеспечения остается до сих пор трудоемким 
процессом; в некотором смысле ее можно назвать кустарным промыслом [1 ]. 
Даже в Японии индустрия программного обеспечения «базируется в основ¬ 
ном на ручных методах, используемых даже на заключительных этапах раз¬ 
работки* [2]. 

Опыт показывает, что проектирование не является точной наукой. Рас¬ 
смотрим, например, разработку сложной базы данных с использованием мо¬ 
дели отношений между объектами — одной из основ объектно-ориентирован¬ 
ного проектирования. «Если говорить честно, важность отдельных объектов 
процесса определяется в значительной степени личными вкусами разработчи¬ 
ка. В результате этого процесс проектирования не является детерминирован¬ 
ным: разные авторы могут составить разные модели одного и того же про¬ 
цесса» [31. 

Поэтому мы приходим к выводу о том, что каким бы сложным ни был 
метод проектирования, какими бы солидными ни были его теоретические ос¬ 
новы, нельзя игнорировать практические аспекты проектирования, которые 
сложились на сегодняшний день для решения практических задач. Это озна¬ 
чает, что мы должны принимать во внимание такие практические приемы 
управления процессом разработки программного обеспечения, как распределе¬ 
ние ресурсов, установление промежуточных этапов, управление конфигура¬ 
цией и проверка версий. Для профессионального разработчика программного 
продукта это реальности, с которыми надо считаться, если хочешь создать 
сложную программную систему. Поэтому в данной главе рассматривается 
применение традиционных методов в объектно-ориентйрованном проектирова¬ 
нии, оценивается их значение в жизненном цикле разработки и влияние на 
практику управления процессом разработки. 

7.1. ОБЪЕКТНО-ОРИЕНТИРОВАННОЕ ПРОЕКТИ¬ 
РОВАНИЕ В ЖИЗНЕННОМ ЦИКЛЕ РАЗРАБОТКИ 
Жизненный цикл разработки программного обеспечения 

На рис. 7-1 показаны этапы традиционного цикла разработки программ¬ 
ного обеспечения, характеризуемого лавинообразным нарастанием сложности. 
Во многих компаниях такая схема обычно соответствует этапам процесса 
разработки систем и ее часто рассматривают как незыблемую. При этом 
считается, что работа, как вода, перетекает вниз с одного этапа на другой. 
Часто даже организационная структура таких фирм соответствует 
приведенной схеме. Но несмотря на силу традиций, недостатки 
лавинообразной модели признаются почти всеми. Боэм, например, 
формулирует эти недостатки следующим образом: 

* «Непригодность для разработки сложных программных систем, состоящих 
из большого числа автономных модулей, а также для организации 
процесса внесения в систему последующих изменений. 

* Обязательно последовательное выполнение всех этапов разработки. 
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Рис. 7-1. Традиционный лавинообразный цикл разработки программного 
обеспечения. 

* Несовместимость с эволюционным подходом, который широко внедряется в 
настоящее время благодаря возможностям быстрого прототипирования и 
применения алгоритмических языков четвертого поколения. 

* Несовместимость с перспективными методами разработки: возможностями 
автоматического программирования, трансформации программ и примене¬ 
ния вспомогательных средств, основанных на базах знаний» [4]. 

Следует особо отметить третий недостаток, поскольку, как мы выше не 
раз говорили, объектно-ориентированное проектирование представляет собой 
поступательный итеративный процесс, что совершенно не согласуется с 
одним из основных постулатов сторонников лавинообразной модели, по 
которому в отлаженный один раз программный продукт очень сложно 
вносить затем какие-либо изменения. Как пишут Хэтли и Пирбхам: «Это 
искажает естественный ход процесса работы над системой, который всегда 
является итеративным и в котором результаты одного из этапов могут изме¬ 
нить решения, принятые на предыдущих этапах» [5]. В первую очередь по 
этой причине Боэм выдвинул спиральную модель создания программного 
обеспечения. 

Однако, понимая, что объектно-ориентированное проектирование есть 
последовательный итеративный процесс, не следует отказываться от 
полезных практических советов по управлению процессом разработки, 
основанных на опыте применения лавинообразной модели. Важным остается 
этап анализа, но необходим и четко выраженный этап проектирования. Од- 
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нако для руководителя и разработчика, привыкших к лавинообразной струк¬ 
туре процесса создания программных систем, объектно-ориентированное про¬ 
ектирование выглядит чуждым и пугающим, поскольку некоторые традици¬ 
онные приемы организации работы теряют в нем всякий смысл. Интеграция, 
например, в объектно-ориентированном проектировании не выделяется в 
отдельный этап, а рассматривается как непрерывный процесс. 

На рис. 7-2 показана диаграмма жизненного цикла разработки програм¬ 
много обеспечения при объектно-ориентированном проектировании. Мы ви¬ 
дим, что проектирование не является отдельным монолитным этапом; скорее 
оно представляет собой один из шагов на пути последовательной итератив¬ 
ной разработки системы, при этом последовательность шагов может иметь 
произвольный характер. В следующих разделах мы рассмотрим, каким обра¬ 
зом при использовании объектно-ориентированного подхода можно оценить 
численность разработчиков, определить номенклатуру необходимых промежу¬ 
точных документов, организовать процессы выпуска программ, обеспечения 
качества и программной поддержки. Вначале рассмотрим этапы жизненного 
цикла объектно-ориентированной разработки программного обеспечения. 

Анализ 

Действия при анализе. На этапе анализа происходят первые встречи 
разработчиков и будущих пользователей системы, которые, исходя из 
особенностей поставленной задачи, пытаются найти между собой общий 
язык. Как считают Меллор и другие: «Целью анализа является описание за¬ 
дачи». Описание должно быть полным, последовательным, доступным для 
чтения и обзора различными заинтересованными сторонами, позволяющим 
проводить сравнение с реальными условиями» [6]. Продукт анализа часто 
используется затем для описания основных функций системы. Говоря о фун¬ 
кции, мы не имеем ввиду алгоритмический термин. В контексте анализа 
требований к системе функция — это обособленный, наблюдаемый и конт¬ 
ролируемый фрагмент поведения. Например, функцией системы организации 
информации является обеспечение различных видов поиска в базе данных. 

Граница между анализом и проектированием весьма расплывчата. Опре¬ 
деление ключевых абстракций предметной области может рассматриваться, 
например, и как часть анализа, и как часть проектирования. Тем не менее 
цели анализа и проектирования совершенно различны. При анализе мы пы¬ 
таемся моделировать окружающий мир, идентифицируя классы и объекты, 
образующие словарь предметной области; при объектно-ориентированном про¬ 
ектировании мы придумываем абстракции и механизмы, обеспечивающие по¬ 
ведение, которое требует эта модель. Другими словами, анализ определяет 
требуемое поведение системы, которую мы должны создать, в то время как 
при проектировании разрабатываются чертежи этой системы. 

Необходимо разделять действия, выполняемые при анализе и проектиро¬ 
вании. Нет ничего хуже, чем получить документ с требованиями, часть из 
которых в действительности не является требованиями, а содержит указания 
о том, что вы должны проектировать систему определенным образом. С дру¬ 
гой стороны, опасно пытаться «полностью» проанализировать систему, даже 
не подумав заранее о том, как приступать к проектированию. Такой подход 
не позволил бы успешно завершить анализ. 
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Рис. 7-2. Цикл разработки программного обеспечения с использованием 
объектно-ориентированного подхода. 

Методы анализа. Существует много методов анализа, которые можно 
использовать до начала объектно-ориентированного проектирования. Наиболее 
известным методом является структурный анализ, изложенный в работах 
Йордона [7], Де Марко [8], Гейна и Сарсона [9], Уорда и Меллора [10], 
Хетли и Пирбхаи [11]. Мы считаем, что результат любого из многочислен¬ 
ных методов структурного анализа можно использовать как исходный мате¬ 
риал для объектно-ориентированного проектирования [12]. Как мы уже 
говорили в гл. 4, анализ абстракций связывает диаграммы потоков данных, 
полученные при структурном анализе, с классами и объектами объектно- 
ориентированного проектирования. 

Заманчиво предварять объектно-ориентированное проектирование струк¬ 
турным анализом, поскольку этот метод хорошо известен, им владеют мно¬ 
гие специалисты, поддержка его обеспечивается обширными библиотеками 
программ. Однако структурный анализ не рекомендуется использовать на на¬ 
чальном этапе объектно-ориентированного проектирования, так как при 
анализе диаграмм потоков данных трудно отделить составную модель задачи 
от проектного решения. Кроме того, на результаты структурного анализа 
иногда влияет алгоритмически-ориентированный подход к задаче, что сильно 
усложняет объектно-ориентированное проектирование. 

Современной тенденцией является применение объектно-ориентированно¬ 
го анализа, описанного в работах Шлеера и Меллора [13], Коуда и Йордо¬ 
на [14]. По определению Смита и Токи, объектно-ориентированный анализ 
включает «процесс идентификации и моделирования основных классов и 
объектов, логических отношений и взаимодействий между ними» [15]. Этот 
процесс достаточно близок к объектно-ориентированному проектированию. 
Практически это означает, что результаты объектно-ориентированногО анали¬ 
за могут непосредственно использоваться на начальном этапе процесса объ- 
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ектно-ориентированного проектирования. Далее разработчик лишь 
модифицирует результаты анализа, вводя новые абстракции и механизмы, 
которые позволяют более эффективно использовать уже идентифицированные 
классы и объекты. 

Перед началом объектно-ориентированного проектирования могут приме¬ 
няться и другие методы анализа, включая SADT [16], SREM [17], модели¬ 
рование соотношений между объектами. Вне зависимости от примененного 
метода важно, что результат анализа предоставляет разработчику достаточно 
полную модель задачи, к решению которой он может приступать. 

Проектирование 

Начало процесса проектирования. Когда начинается проектирование? 
Практически тогда, когда мы имеем некую (возможно полную) формальную 
или неформальную модель поставленной задачи. Если мы начнем проектиро¬ 
вание слишком рано, исходных сведений о задаче может не хватить для то¬ 
го, чтобы принимать обоснованные компромиссные решения при проектиро¬ 
вании. Если проектирование начинается слишком поздно, мы рискуем потра¬ 
тить много сил на подробный анализ, который «обрушится» на разработчика 
лавиной лишних и ненужных подробностей. Поэтому мы предлагаем 
следующую стратегию разработки, которую назовем «немного анализа, не¬ 
много проектирования». В этой стратегии каждый шаг проектирования на¬ 
правляет процесс анализа на выявление тех аспектов системы, которые важ¬ 
ны для получения решения. 

В реальных условиях специалисты, занимающиеся анализом и разработ¬ 
кой, не всегда могут быть тесно связаны друг с другом. Так бывает, когда 
разработку частей программного обеспечения выполняют субподрядчики. Од¬ 
нако это не должно препятствовать применению стратегии «немного анализа, 
немного проектирования». Попытайтесь проектировать, базируясь на вашем 
понимании требований в данный момент времени. Остановитесь, изучите до¬ 
стоинства и недостатки полученных результатов и попытайтесь их улучшить. 
Эта операция помогает разработчику уточнить понимание требований и 
скорректировать процесс анализа. Мы не выступаем здесь сторонниками про¬ 
ектирования методом проб и ошибок. Скорее мы предлагаем проектировать, 
используя разумно выбранные прототипы, каждый из которых моделирует 
одну из частей системы, причем совокупность этих прототипов наращивает 
со временем свои функциональные возможности. 

Конец процесса проектирования. Когда прекращать процесс проектиро¬ 
вания? Это важный вопрос, поскольку существует опасность перегрузки 
системы. Архитектор редко задумывается над тем, чтобы указать на общем 
плане дома места прокладки трубопроводов, системы отопления или установ¬ 
ки выключателей. Есть решения, которые нужно принимать на месте как 
часть процесса внедрения или, если существуют специальные требования, на 
нижнем уровне проектирования, выполняемом электриками или теплотехни¬ 
ками. Так же должно быть при проектировании систем программного обес¬ 
печения. Предлагайте только ключевые абстракции и важные механизмы, 
достаточные для реализации, и откладывайте на более поздний период те 
аспекты решения, которые оказывают незначительное влияние на видимое 
поведение системы. 

Разбивайте большую задачу на подзадачи так., чтобы их решения были 
доступны специалисту в данной специфической области. В большой системе 
можно, например, выделить проблемы сетей баз данных или интерфейса 
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пользователя. Простой признак необходимости прекращения процесса проек¬ 
тирования состоит в том, что полученные ключевые абстракции оказываются 
просты и не требуют дальнейшей декомпозиции; в то же время их можно 
составить из существующих, повторно используемых элементов программного 
обеспечения. 

Эволюция системы 

Действия. Эволюция системы в жизненном цикле разработки объектно- 
ориентированного программного обеспечения совмещает традиционные этапы, 
включающие составление программ, их тестирование и интеграцию 
(комплексирование). Поэтому при объектно-ориентированном проектировании 
мы никогда не сталкиваемся с отдельным этапом интеграции системы. Вме¬ 
сто этого процесс разработки превращается в постепенное составление ряда 
прототипов, которые затем входят в конечную реализацию. 

Пэйдж-Джонс указывает на ряд преимуществ такого метода постепенной 
разработки: 

* «Пользователю предоставляется обширная обратная связь тогда, когда она 
наиболее необходима, наиболее полезна и важна. 

* Пользователям предоставляются различные версии структур систем, позво¬ 
ляющие обеспечивать плавный переход от старой системы к новой. 

* Меньше возможностей отмены проекта, если он запаздывает относительно 
установленного срока. 

* Интерфейс главной системы тестируется в первую очередь и неоднократно. 

* Более равномерно распределены ресурсы тестирования. 

* Специалисты, занимающиеся реализацией могут видеть уже на ранних 
стадиях разработки результаты работы системы. 

* При нехватке времени кодирование и тестирование могут начинаться до 
окончания проектирования» [19]. 

Мы добавили бы к этому перечню следующее: составление развиваю¬ 
щихся прототипов стимулирует разработку и оценку альтернативных реше¬ 
ний, что позволяет получить разумный компромисс. Такая практика являет¬ 
ся обычной в других инженерных дисциплинах; к сожалению она редко 
встречается в программировании. При разработке системы всегда необходимо 
найти решение, удовлетворяющее ряду ограничений, которые соответствуют, 
в частности, функциональным требованиям, требованиям на сроки разработ¬ 
ки и занимаемый объем. Определяющим является самое жесткое ограниче¬ 
ние. Например, если критическим фактором является вес ЭВМ (при созда¬ 
нии системы для космического корабля), необходимо учесть вес отдельных 
схем памяти. Разрешенный по условиям веса объем памяти ограничивает 
размер загружаемой программы. Если некоторое ограничение ослабляется, 
становятся возможными некоторые альтернативные решения; наоборот, если 
ограничение ужесточается, некоторые альтернативы становятся. бесполезными. 
В процессе постепенной эволюции системы программного обеспечения мы 
можем определить, какое ограничение является действительно важным, а ка¬ 
кое — нет. Оправданным подходом является проектирование, направленное 
в первую очередь на выполнение заданных функций и во вторую очередь 
на обеспечение характеристик, поскольку на ранних стадиях проектирования 
из-за недостатка сведений трудно понять, какая из характеристик будет «уз¬ 
ким местом» системы. Анализируя поведение прототипов с помощью гистог¬ 
раммы или другим способом, разработчик может лучше понять, как дово¬ 
дить систему в будущем. 
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Изменения в процессе эволюции системы. Практика показывает, что в 
процессе эволюции системы в ней могут произойти следующие изменения: 

* Добавление нового класса. 

* Изменение реализации класса. 

* Изменение представления класса. 

* Реорганизация структуры класса. 

* Изменение интерфейса класса. 

Каждый вид изменений вызывается различными причинами и имеет 
различную стоимость. 

Разработчик добавляет в систему новые классы, когда вводятся новые 
ключевые абстракции и предлагаются новые механизмы. Цена этих измене¬ 
ний, связанных с перераспределением вычислительных ресурсов и расходами 
на управление, обычно незначительна. 

Также не требует больших затрат изменение реализации класса. При 
объектно-ориентированном проектировании мы обычно сначала создаем ин¬ 
терфейс класса, а затем его реализацию. Когда интерфейс в значительной 
мере стабилизирован, мы можем выбрать представление данного класса и 
завершить составление методов. Реализация частного метода может быть 
снова изменена, обычно для того чтобы устранить ошибку или улучшить 
характеристики. Мы можем также изменить реализацию метода, для того 
чтобы воспользоваться преимуществами новых методов, определенных в су¬ 
ществующих или вновь добавленных суперклассах. В любом случае измене¬ 
ние реализации метода не требует больших затрат, в особенности если зара¬ 
нее ограничен доступ к реализации класса. 

Аналогичным образом можно изменить представление класса. Обычно 
это делается для повышения эффективности объектов класса или создания 
более эффективных методов. Если доступ к представлению класса ограничен, 
что возможно при использовании языков Smalltalk, C++, CLOS и Ada, то 
изменение представления не меняет логики взаимодействия объектов-пользо- 
вателей с объектами данного класса (конечно, если новое представление от¬ 
ражает ожидаемое поведение класса). С другой стороны, если доступ к 
представлению класса не ограничен, что также возможно в Object Pascal, 
C++ и Ada, то изменение представления значительно более опасно, посколь¬ 
ку объекты-пользователи могут быть записаны так, что они взаимодействуют 
только с определенной реализацией класса. Это в особенности относится к 
подклассам: изменение представления суперкласса влияет на представление 
всех подклассов. В любом случае изменение представления класса требует 
затрат: нужно переработать его интерфейсы, его реализации, все объекты- 
пользователи (а именно, их подклассы и объекты), все объекты-пользователи 
его обьектов-пользователей и т.д. Реорганизация структуры классов системы 
является обычной операцией, хотя и не такой частой, как другие измене¬ 
ния, о которых мы говорили выше. Как заметили Стефик и Бобров: «Про¬ 
граммисты часто создают новые классы и реорганизуют существующие, ког¬ 
да замечают новые возможности для их программ» [20]. Реорганизация 
структуры классов обычно принимает форму изменения наследственных свя¬ 
зей, добавление новых абстрактных классов и сдвига реализаций обычных 
методов в сторону высших классов в структуре. На практике реорганизация 
структуры классов системы особенно часто производится в начальный пери¬ 
од, а затем, когда разработчики лучше начинают понимать взаимодействие 
ключевых абстракций, структура стабилизируется. Реорганизацию структуры 
классов следует поощрять на ранних этапах проектирования, поскольку она 
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может привести к значительной экономии выразительных средств, при этом 
нам придется создавать и поддерживать меньшее число реализаций и клас¬ 
сов. Однако реорганизация структуры классов не проходит без затрат. Как 
правило, перемещение класса вверх по иерархической структуре делает не¬ 
нужными все более низкие классы и требует их перетрансляции (и следова¬ 
тельно, перетрансляции всех классов, которые зависят от них и т.д.). 

Таким же важным видом изменений, которые встречаются при эволю¬ 
ции системы, является изменение интерфейса класса. Разработчик обычно 
изменяет интерфейс класса для того, чтобы добавить ему некоторое новое 
свойство или операцию, которая и раньше была частью абстракции, но вна¬ 
чале не была учтена, а затем потребовалась объекту-пользователю. На 
практике, применяя эвристические методы для создания классов качества, 
которые рассматривались в гл. 3 (в частности, концепции создания простых, 
достаточных и полных интерфейсов), можно уменьшить вероятность таких 
изменений. Однако наш опыт показывает, что такие изменения неизбежны. 
Нам никогда не удавалось написать нетривиальный класс, который с первого 
раза имел правильный интерфейс. 

Мы редко исключаем уже существующий метод; обычно это делается 
для того, чтобы ограничить доступ к абстракции. Чаще мы добавляем метод 
или вводим новый заменяющий метод, определенный в некотором суперклас¬ 
се. Во всех трех случаях изменение требует затрат, поскольку оно логиче¬ 
ски воздействует на все объекты-пользователи, требуя их перетрансляции. К 
счастью, два последних вида изменений — добавление и замена существую¬ 
щего метода — являются совместимыми снизу вверх. Действительно, прак¬ 
тика показывает, что более трех четвертей всех изменений интерфейсов, 
производимых при эволюции системы, являются совместимыми снизу вверх. 
Это позволяет применять для снижения влияния этих изменений сложные 
методы трансляции, такие, как пошаговая трансляция. Пошаговая трансля¬ 
ция позволяет перетранслировать отдельные описания и операторы вместо 
изменения всего модуля. 

Почему так важны затраты на перетрансляцию? Они невелики для ма¬ 
лых систем, где повторная трансляция всей программы может продолжаться 
всего несколько минут. По-другому обстоит дело в больших системах. Ре¬ 
трансляция программы объемом в миллион строк может потребовать работы 
ЭВМ в течение целого дня. Можете ли вы представить ситуацию, когда не¬ 
обходимо изменить программное обеспечение судовой ЭВМ, и вы заявляете 
капитану, что он не может выйти в море из-за того, что вы производите 
перетрансляцию? В принципе затраты на повторную трансляцию могут быть 
настолько высокими, что разработчику будет запрещено вносить изменения, 
несмотря на то, что они дают существенные улучшения. Ретрансляция име¬ 
ет большое значение при использовании объектно-ориентированных языков 
программирования из-за вносимых наследованием связей [21 ]. При использо¬ 
вании типовых объектно-ориентированных языков программирования затраты 
на перетрансляцию могут быть очень высокими; в этом случае надо искать 
компромисс между временем трансляции и надежностью. 

Чтобы избежать ошибок при эволюции разрабатываемой системы, нужно 
соблюдать два правила: следить за созданием устойчивых интерфейсов и ог¬ 
раничивать доступ к проектным решениям, которые могут изменяться. 
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Рис. 7-3. Распределение временных ресурсов при использовании объект¬ 
но-ориентированного подхода. 

Модификации 

Леман и Белади сделали ряд замечаний, касающихся совершенствования 
программного обеспечения: 

• «Программа, которая реально используется, обязательно должна изменять¬ 
ся, иначе она будет все менее и менее пригодной для использования (за¬ 
кон непрерывного изменения). 

* Когда программа изменяется, ее структура становится более сложной, если 
при этом не предпринимаются активные усилия с целью предотвратить 
усложнение (закон увеличения сложности)» [221. 

Поэтому мы. отличаем сохранение программного обеспечения от его со¬ 
провождения. При сопровождении программного обеспечения от разработчика 
могут потребовать добавить новые функциональные возможности или моди¬ 
фицировать некоторые имеющиеся свойства. Сопровождением часто занима¬ 
ется другая группа специалистов, а не разработчики первоначального про¬ 
граммного обеспечения. 

Опыт показывает, что при модификации выполняются действия, не¬ 
сколько отличающиеся от действий, проводимых при эволюции системы. Ес¬ 
ли объектно-ориентированное проектирование с самого начала проводилось 
достаточно тщательно, то добавление новых функциональных возможностей 
или модификация некоторого существующего свойства является естественной 
операцией. Это подтверждается практикой даже для самых больших систем. 

7.2. УПРАВЛЕНИЕ ПРОЕКТОМ 
Подбор кадров 

Распределение ресурсов. Мы пришли к выводу, что применение объект¬ 
но-ориентированного проектирования позволяет сократить график разработки 
и обеспечить более высокое качество программного продукта, что помогает 
удовлетворить наиболее часто встречающимся требованиям к процессу 
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разработки программных систем. Одной из самых неожиданных сторон таких 
проектов оказывается возможность уменьшения общего колличества требуе¬ 
мых ресурсов и изменение временных соотношений между разными этапами 
процесса. Рис. 7-3 иллюстрирует эти соотношения. По вертикальной оси 
отложено количество затраченных человеческих ресурсов в месяцах на одно¬ 
го инженера. Жирная горизонтальная линия соответствует уровню ресурсов, 
обычно требуемому при традиционном лавинообразном цикле разработки. 
При использовании объектно-ориентированного подхода ресурсы должны быть 
распределены иначе. На анализ они тратятся примерно в том же 
количестве, но на проектирование их тратится больше, так как на этом 
этапе завершается больший объем работ, чем при обычном подходе. Такое 
увеличение не обязательно должно приводить к большему числу занятых 
людей; чаще оно подразумевает достаточно продолжительную работу неболь¬ 
шого числа хороших специалистов. Для кодирования же объектно-ориентиро¬ 
ванный подход требует меньше ресурсов, так как оставшаяся после проекти¬ 
рования работа в большей степени носит ограниченный характер. Тестирова¬ 
ние также занимает меньше ресурсов в основном из-за того, что придание 
классу новых функциональных возможностей достигается главным образом за 
счет модификации существующего класса, поведение которого уже достаточ¬ 
но отработано. И наконец, интеграция системы в одно целое занимает го¬ 
раздо меньше времени по сравнению с традиционными подходами, так как 
фактически процесс интеграции происходит на протяжении всего цикла раз¬ 
работки. Общая сумма человеческих ресурсов, требуемых при объектно-ори¬ 
ентированном подходе, обычно примерно равна или даже меньше требуемых 
при традиционном проектировании, и конечный продукт имеет тенденцию к 
улучшению. 

Распределение ролей в команде разработчиков. Мы уже видели, как 
распределяются роли среди членов группы разработчиков программного обес¬ 
печения. При объектно-ориентированном подходе существует необходимость в 
четырех типах специалистов: 

* Архитекторы систем. 

* Проектировщики классов. 

* Специалисты, реализующие внутреннее строение классов. 

* Программисты-прикладники. 

Архитекторы систем — это провидцы. Они относятся к числу наиболее 
уважаемых разработчиков и лучше других подготовлены для принятия стра¬ 
тегических проектных решений. Следующим наиболее уважаемым специали¬ 
стам доверяется роль проектировщиков классов, ответственных за создание 
системных структур классов и разработку механизмов. Каждый проектиров¬ 
щик классов несет ответственность главным образом за создание и поддерж¬ 
ку интерфейса какой-либо важной категории классов или подсистемы. Более 
молодые специалисты выступают в роли разработчиков внутреннего строения 
классов. Они не имеют столь широких знаний' в области проектирования ар¬ 
хитектуры классов, но знают, как правильно представить класс и реализо¬ 
вать это представление. Разработчики внутреннего строения классов обычно 
работают под непосредственным руководством проектировщика классов. Про¬ 
граммисты-прикладники — наиболее молодые специалисты, являющиеся тем 
не менее экспертами в предметной области. Они берут результаты работы 
специалистов в области внутреннего строения классов и собирают их, ис¬ 
пользуя механизмы, предложенные проектировщиками классов, для придания 
системе требуемых свойств. 
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Такое распределение труда формирует задачу подбора кадров под опре¬ 
деленную работу; с подобными задачами приходится сталкиваться организа¬ 
циям, занимающимся разработкой программного обеспечения, в которых ра¬ 
ботает небольшое число специалистов высокого уровня и значительное число 
менее опытных программистов. К преимуществам изложенного подхода мож¬ 
но отнести обеспечение возможности профессионального роста для молодых 
специалистов, которые постоянно работают в тесном контакте со своими 
старшими коллегами. В процессе того, как они набираются опыта, пользуясь 
хорошо сконструированными классами, растет вероятность того, что со вре¬ 
менем они смогут качественно проводить аналогичную работу. 

Объектно-ориентированное проектирование делает возможным использо¬ 
вание меньших по составу групп. Нет ничего необычного в том, что группа 
примерно из 30—40 человек выдает в год более миллиона строк хорошо от¬ 
лаженной программной продукции. Здесь мы согласны с Боэмом, который 
считает, что «лучшие результаты получаются в результате работы меньшего 
числа лучших людей» [23 ]. К сожалению, попытки набрать под проект 
меньшее количество народа, чем рекомендовано традиционным подходом, мо¬ 
гут вызвать сопротивление. Такие попытки перечеркивают старания некото¬ 
рых управленцев создать себе империю. Подобные управленцы очень любят 
прятаться за спину большого количества сотрудников, ведь такое подкрепле¬ 
ние придает дополнительную уверенность в своих силах. И кроме того, в 
случае неудачи всегда будет на кого списать грехи. 

Однако самый передовой метод проектирования — еще не повод для 
менеджера освобождать себя от ответственности, когда речь идет о наборе 
кадров; ведь небезразлично, кто это будут: думающие сотрудники или пер¬ 
сонал, отдавший судьбу проекта на волю случая [24]. Управление — актив¬ 
ный процесс, отнюдь не пассивный. 

Этапы и результаты 

Этапы. Наверно, основная причина того, что процесс объектно-ориенти¬ 
рованного проектирования кажется менеджерам, впервые сталкивающимся с 
ним, чуждым для восприятия, заключается в непонимании, каким образом 
поступательный и итеративный процесс может обеспечить прогресс по срав¬ 
нению с традиционными подходами. Прогресс можно измерять количеством 
времени, затраченным на завершение того или иного этапа. В этом случае 
мы не видим большой разницы по сравнению с существующими методами. 
Разница заключается в том, что понимать под успешным завершением эта¬ 
па. 

В процессе разработки очень полезно провести несколько официальных 
и гораздо большее количество неофициальных обсуждений промежуточных 
итогов работы. На ранних этапах экспертам, будущим пользователям и раз¬ 
работчикам обычно необходимо обсудить структуру прототипов будущих 
классов и их основные механизмы. По мере выделения ключевых абстрак¬ 
ций и механизмов при обсуждениях начинают затрагиваться более деталь¬ 
ные вопросы логического и физического проектирования. На этом, более 
позднем, этапе обсуждение включает демонстрации и анализ уже работаю¬ 
щих прототипов. 

Таким образом пользователи, менеджеры и разработчики системы полу¬ 
чают представление о том, в каком состоянии на данный момент находится 
работа. Клиент может лучше чувствовать прогресс, видя работающие прото¬ 
типы и обсуждая промежуточные результаты. Менеджеры могут иметь в 
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распоряжении те же материалы, но оценивать их, как мы увидим ниже, 
несколько по-другому. 

Это, наверно, самое ужасное, когда менеджер оценивает степень про¬ 
гресса количеством набранных строк. Данный показатель совершенно не кор¬ 
релирует со степенью полноты и завершенности программы. Несмотря на 
все недостатки такого «неандертальского» подхода, им пользуются из-за 
простоты, которую он предоставляет при манипуляциях с цифрами, вылива¬ 
ющимися в безумные показатели производительности для одних и служа¬ 
щими немым укором для других. Как, например, считать строки програм¬ 
мы? По физическим строкам или по точкам с запятой? Как сравнивать не¬ 
сколько выражений на одной строке с одним выражением, имеющим очень 
большую длину? А как можно измерить затраченный труд? Считать весь 
персонал или только программистов? Измерять рабочий день восемью часами 
или добавлять все дополнительное время, которое тратит бедный инженер, 
просиживая на работе до утра? Традиционные методы оценки, больше рас¬ 
считанные на ранние поколения программных языков, почти не коррелируют 
со степенью завершенности и полноты программы и, таким образом, беспо¬ 
лезны применительно к объектно-ориентированным программным языкам. 

Гораздо лучший способ оценки продуктивности дает опыт постоянной 
интеграции. Подобный эволюционный подход не предполагает наличия неко¬ 
его «большого интеграционного скачка»; вместо этого прогресс измеряется 
качеством законченных и работающих классов, если это логическое проекти¬ 
рование, или модулей, если это физическое проектирование. Другой путь 
оценки уровня состояния работ — оценка устойчивости ключевых интерфей¬ 
сов (т.е. как часто они модифицируются). Вначале интерфейсы всех ключе¬ 
вых абстракций меняются каждый день, если не каждый час. С течением 
времени наиболее важные интерфейсы стабилизируются в первую очередь, 
интерфейсы следующего уровня важности — во вторую очередь, и т.д. К 
концу цикла разработки изменений будут требовать лишь некоторые второ¬ 
степенные интерфейсы; это произойдет, когда основное внимание будет уде¬ 
лено вопросу стыковки уже разработанных между собой классов и модулей. 
Иногда возникает необходимость внести некоторые изменения в конечный 
интерфейс, но подобные изменения обычно нс вызывают цепной реакции и 
носят локальный характер. Но даже в этом случае их внесение должно со¬ 
провождаться детальной проработкой возможных последствий. Только затем 
их можно постепенно ввести в продукт как часть изменений обычного цик¬ 
ла модернизации, о котором мы скоро поговорим. 

Часто приходится увязывать последовательный и итеративный процесс 
объектно-ориентированного проектирования с жесткими требованиями, нала¬ 
гаемыми внешними действующими лицами. Особенно часто это приходится 
делать, когда проект финансируется из государственных источников. Подо¬ 
бные трудности могут быть устранены, если заказчик с сочувствием отно¬ 
сится к реалиям процесса разработки программного обеспечения и может 
позволить определенную вольность интерпретации документов, определяющих 
технические требования к системе. Вместо того чтобы, например, документи¬ 
ровать ввод, обработку и вывод, мы описываем интерфейсы и поведение 
объектов. 

Результаты. Разработка программной системы представляет собой нечто 
большее, чем простое написание исходных модулей. После завершения про¬ 
ектирования остаются еще и другие продукты, позволяющие менеджеру и 
пользователю полнее уяснить себе суть проекта и, что не менее важно, 
13 Гради Буч 
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иметь тем, кто будет в конечном итоге заниматься поддержкой системы, го¬ 
товый банк проектных решений. Продукты объектно-ориентированного проек¬ 
тирования — это, как отмечено в гл. 5, диаграммы .классов, модулей, про¬ 
цессов и объектные диаграммы. Все диаграммы основываются в конечном 
итоге на требованиях к программной системе. Диаграммы процессов опреде¬ 
ляют программы, которые в свою очередь являются корневыми модулями в 
диаграммах модулей. Каждый модуль реализует соответствующую комбина¬ 
цию классов и объектов, определяемых по своим диаграммам. И наконец, 
по диаграммам объектов создаются механизмы, соответствующие требованиям 
к системе, а диаграммы классов представляют ключевые абстракции, форми¬ 
рующие словарь предметной области. 

Так как эти результаты должны рассматриваться в общем контексте, то 
в документации они должны быть сгруппированы определенным способом. 
Проект каждого значительного сегмента системы должен быть описан в от¬ 
дельном документе. На практике наилучшим образом отражает логическую 
схему нашей системы, скорее всего, документ, имеющий следующую струк¬ 
туру: 

* Требуемые функции. 

* Диаграммы классов и объектов. 

* Базовые элементы классов и объектов. 

* Результаты в виде работающих прототипов. 

Позднее, в процессе разработки, данный документ можно расширить, 
включив в него все необходимые решения, и его структура, в результате, 
возможно, будет выглядеть следующим образом: 

* Требуемые функции. 

* Диаграммы классов и объектов. 

* Базовые элементы классов и объектов. 

* Диаграммы модулей и процессов. 

* Базовые элементы модулей и процессов. 

* Результаты в виде работающих прототипов. 

Большинство разделов данного документа могут быть написаны с по¬ 
мощью полуавтоматических методов. 

Выпуск продукта 

Дэвис и другие отмечают, что «когда процесс разработки носит по¬ 
следовательный характер, программный продукт сначала удовлетворяет лишь 
небольшому числу требований, но он создается таким образом, чтобы в 
дальнейшем облегчить переход к новым требованиям и, следовательно, до¬ 
стичь более высокого уровня адаптивности» [25]. Если встать на точку зре¬ 
ния конечного пользователя системы, то он хотел бы видеть ряд работаю¬ 
щих прототипов, поступающих от организации-разработчика, каждый из ко¬ 
торых обладал бы более высокими функциональными возможностями по 
сравнению с предыдущим и постепенно приближался бы к требуемой систе¬ 
ме. С точки зрения работников этой организации, из большого числа скон¬ 
струированных прототипов необходимо выбрать наиболее удачные и взять их 
за основу для наиболее важных интерфейсов внутри системы и, таким обра¬ 
зом, передать заказчику наилучший вариант продукта. 

При реализации масштабных проектов организация обычно выпускает 
новый вариант системы «для внутреннего пользования» через каждые не¬ 
сколько недель и затем через каждые несколько месяцев представляет за- 



Традиционные методы 


195 


казчику для оценки новую систему, работающую в соответствии с требова¬ 
ниями проекта. В готовом состоянии такой вариант системы состоит из ряда 
совместимых подсистем (и их модулей), сопровождаемых также соответству¬ 
ющей логической и физической проектной документацией. Создание новою 
варианта представляется возможным, когда основные подсистемы проекта до¬ 
статочно устойчивы и достаточно хорошо стыкуются между собой, чтобы 
можно было безболезненно обеспечить более высокий уровень функциональ¬ 
ных возможностей. 

Рассмотрим данный подход с точки зрения отдельного разработчика, от¬ 
ветственного за создание модулей для определенной подсистемы. Он всегда 
должен иметь рабочий вариант этой подсистемы. Для того чтобы успешно 
завершить разработку, должны иметься в наличии интерфейсы основных 
подсистем. Как только рабочая версия принимает устойчивые очертания, ее 
передают группе тестирования и интеграции, ответственной за сбор из взаи- 
мосовместимых подсистем продукта в целом. В конце концов эти собранные 
подсистемы должны сформировать некоторый окончательный вариант «для 
внутреннего пользования». Собранный вариант становится текущим прототи¬ 
пом системы, доступным тем разработчикам, которые хотят усовершенство¬ 
вать свою часть продукта. Каждый разработчик одновременно может рабо¬ 
тать над новой версией своей подсистемы. Таким образом, работа может ве¬ 
стись параллельно, и устойчивость системы при этом обеспечивается работой 
грамотно организованных и спланированных интерфейсов между отдельными 
подсистемами. 

Практически это означает, что в каждый момент разработки системы 
может существовать множество различных версий отдельных ее модулей: ра¬ 
бочий прототип, прототип для «внутренней» версии и, наконец, последняя 
рыночная версия. Это усиливает необходимость создания четкой схемы 
управления и контроля за состоянием различных версий. Для небольших 
проектов наиболее удобной единицей с точки зрения управления является 
программный модуль. Для более значительных проектов, которые могут со¬ 
стоять из десятков тысяч отдельных модулей, лучше использовать в качест¬ 
ве «единицы измерения» такие категории, как класс или подсистема. 

Исходный текст — не единственный продукт, являющийся предметом 
контроля со стороны менеджера. С подобной же точки зрения могут рас¬ 
сматриваться и другие продукты объектно-ориентированного проектирования, 
например диаграммы классов, объектов, модулей и процессов. 

Контроль качества 

Использование объектно-ориентированного проектирования не дает права 
отказываться от хорошо устоявшейся практики контроля за качеством про¬ 
дукта. Сквозной контроль проекта все еще имеет очень важное значение 
для объектно-ориентированного проектирования. Но преимущество объектно- 
ориентированного подхода состоит в том, что изучение полученных в про¬ 
цессе работы диаграмм помогает уяснить структуру наиболее важных эле¬ 
ментов проекта и сконцентрироваться на самых уязвимых местах, не увяз¬ 
нув при этом в разборе форматов и взаимном согласовании различных мо¬ 
дулей. На ранних стадиях разработки контроль в основном охватывает об¬ 
ласть статических и динамических свойств ключевых абстракций и механиз¬ 
мов системы, отраженных в диаграмме классов и объектов. Позднее конт¬ 
роль охватывает главным образом физический проект системы, отраженный 
в диаграмме модулей и процессов. 
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С проблемой контроля тесно связана проблема тестирования. Следует 
отметить, что применение объектно-ориентированного подхода не меняет 
обычную практику тестирования, изменяется лишь объем тестируемых моду¬ 
лей. Индивидуальное тестирование классов и модулей лучше всего проводить 
программистам, применяющим данные классы в свсих прикладных модулях. 
Так как большинство классов и модулей функционируют неавтономно, раз¬ 
работчику обычно нужно для проведения тестирования создать необходимую 
поддержку их интерфейса. Наверно, лучше не выбрасывать после отладки 
старые тесты и их результаты, так как по мере развития системы они мо¬ 
гут пригодиться в качестве тестов, определяющих способность системы функ¬ 
ционировать по меньшей мере так же, как раньше. 

Целостное тестирование состоит из двух частей. Сначала, до окончания 
работы над подсистемой проектировщик классов проверяет все ее функцио¬ 
нальные возможности. Опыт применения поддержки интерфейса для отдель¬ 
ных классов и модулей здесь тоже пригодится, однако на этом этапе обыч¬ 
но проверяется работа механизма в целом. Затем группа тестирования и ин¬ 
теграции, ответственная за сбор совместимых подсистем в единое целое, 
проводит системные тесты. Она также могут использовать поддержку интер¬ 
фейса для автоматической прогонки старых тестов для каждого нового вари¬ 
анта системы. 

Итак, следует отметить, что главной задачей группы тестирования и 
интеграции является обеспечение политики и стандартов тестирования. От¬ 
ладка модулей проводится, таким образом, программистами, применяющими 
эти модули и классы, тестирование подсистем выполняется проектировщика¬ 
ми классов, а проверка функционирования системы как целого обеспечивает¬ 
ся группой тестирования и интеграции. Пользуясь терминами ключевых абс¬ 
тракций и механизмов, можно сказать, что с помощью этого подхода снача¬ 
ла достигается надежность прежде всего низких уровней абстракций. 

Инструментальная поддержка 

Работая с языками первых поколений, группе разработчиков было до¬ 
статочно иметь минимальный набор инструментов: редактор, транслятор, 
редактор связей и загрузчик — вот часто и все, что требовалось (и скорее 
всего было в наличии). При определенной доле везения иногда даже можно 
было получить отладчик исходных текстов. Появление сложных систем пол¬ 
ностью изменило картину: попытки создать обширную программную систему 
с помощью минимального набора инструментальных средств подобны попыт¬ 
кам построить многоэтажное здание с помощью каменных орудий. 

Появление объектно-ориентированного подхода тоже в свою очередь ме¬ 
няет ситуацию. Традиционные средства разработки программного обеспечения 
могут оперировать только данными об исходных текстах, но, поскольку объ¬ 
ектно-ориентированное проектирование выдвигает на первый план понятия 
ключевых абстракций и механизмов, нам необходимы инструменты, 
содержащие более широкий набор условных обозначений. Мы выделили по 
меньшей мере шесть различных типов инструментальных средств, оказываю¬ 
щихся полезными при объектно-ориентированном проектировании. 

Типы инструментальных средств. Первым инструментом являются гра¬ 
фические системы со встроенными элементами нотаций, представленных в 
гл.5. Подобный инструмент используется на самых ранних этапах процесса 
разработки для выработки некоторых взаимных соглашений по объектно-ори¬ 
ентированному анализу и проектированию, поддержке контроля за продукта- 
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ми разработки и координации деятельности группы. Этот инструмент также 
используется на протяжении всего цикла разработки, по мере того как про¬ 
ект доводится до вполне определенной прикладной системы. Данный инстру¬ 
мент также полезен для последующей поддержки системы. С его помощью, 
например, можно осуществлять «обратную связь» при проектировании объек¬ 
тно-ориентированной системы, т.е. восстанавливать по исходному тексту 
структуру классов и модулей проекта. Это довольно важная особенность: с 
традиционными средствами типа CASE разработчики могут создавать пре¬ 
красные схемы и обнаруживать, что эти схемы устаревают, как только дело 
доходит до применения созданных ими классов, потому что программисты 
начинают подгонять под себя их структуру, забывая изменять соответствую¬ 
щим образом проект. «Обратная связь» уменьшает вероятность того, что до¬ 
кументация к проекту будет отличаться от его фактической реализации. 

Вторым инструментом, важным с нашей точки зрения, при объектно- 
ориентированном проектировании, является инструмент просмотра структуры 
классов и модульной архитектуры системы. Иерархии классов могут оказать¬ 
ся настолько сложными и запутанными, что будет трудно определить абст¬ 
ракции, являющиеся частью проекта или кандидатами на повторное исполь¬ 
зование [26]. При просмотре фрагмента программы разработчику может по¬ 
надобиться найти определение класса, которому принадлежит тот или иной 
объект. Найдя этот класс, он возможно захочет совершить экскурсию туда, 
ще определен тот или иной суперкласс. Просматривая суперкласс, разработ¬ 
чик может выразить желание увидеть все примеры его использования, преж¬ 
де чем приступать к изменению его интерфейса. Подобный просмотр может 
оказаться весьма сложным занятием, если при этом приходится заботиться о 
файлах, которые относятся к физической структуре системы, а не к логиче¬ 
ской. Поэтому инструмент просмотра является таким важным при объектно- 
ориентированном проектировании. Smalltalk, например, позволяет просматри¬ 
вать классы системы именно описанным нами способом. Подобные же воз¬ 
можности существуют, правда в различной степени, во всех программных 
языках, которые мы используем в этой книге. 

Третий с нашей точки зрения важный, если не определяющий, инстру¬ 
мент — это пошаговый транслятор. Как мы выше отметили, тот эволюцион¬ 
ный тип разработки, который определяется объектно-ориентированным подхо¬ 
дом, с необходимостью влечет за собой появление пошагового транслятора, 
обеспечивающего трансляцию отдельных операторов и функций. Мейрович 
считает, что «ОС Юникс в том виде, в каком она сейчас находится (с ори¬ 
ентацией на пакетный режим трансляции больших программных файлов и 
переводом их в библиотечные модули, которые затем объединяются с други¬ 
ми модулями), не обеспечивает необходимую поддержку для объектно-ориен¬ 
тированного программирования. Совершенно неприемлемо тратить 10 мин. на 
трансляцию и редактирование только для того, чтобы изменить один из ме¬ 
тодов, и тратить целый час на трансляцию и редактирование, чтобы доба¬ 
вить одну переменную в структуру суперкласса высокого уровня! Пошагово¬ 
транслируемые методы и пошагово-транслируемые описатели необходимы для 
быстрой отладки» [27]. Пошаговые трансляторы существуют для большинства 
языков, описанных в этой книге, однако большинство их реализаций содер¬ 
жит традиционные трансляторы, ориентированные на пакетный режим. 

Кроме того, почти для всех нетривиальных проектов необходимо нали¬ 
чие отладчиков, понимающих семантику классов и объектов. При отладке 
часто требуется проверить значение переменной объекта и переменной клас- 
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са, связанной с объектом. Традиционные отладчики для обычных программ¬ 
ных языков не содержат знания о классах и объектах. Пытаясь, таким об¬ 
разом, использовать стандартный Си-отладчик для программ, написанных на 
C++, мы, даже если это нам удастся, не можем получить по-настоящему 
важную информацию для отладки объектно-ориентированной программы. 
Наиболее тяжелая ситуация складывается с объектно-ориентированными язы¬ 
ками, поддерживающими мультипрограммный режим работы компьютера. В 
каждый данный момент работы такой программы может существовать не¬ 
сколько активных процессов. В подобных случаях требуется отладчик, позво¬ 
ляющий разработчику осуществлять контроль за каждым из процессов, 
обычно по схеме «обьект-за-обьектом*. 

При реализации больших проектов необходимо также следить за их 
конфигурацией и иметь инструмент контроля за версиями. Как было выше 
замечено, для небольших проектов наилучшей единицей контроля может 
служить отдельный модуль; для более сложных проектов наиболее приемле¬ 
мой единицей является подсистема. 

Последний инструмент, на котором мы остановим внимание при рас¬ 
смотрении объектно-ориентированного проектирования, — это библиотекарь 
классов. Большинство языков, которыми мы пользуемся в этой книге, имеют 
заранее определенные библиотеки классов. По мере доводки проекта эти 
библиотеки растут, так как к ним с течением времени добавляются модули, 
созданные разработчиком. Через довольно короткое время такая библиотека 
может вырасти до огромных размеров, и в результате разработчик скорее 
всего встретится со значительными трудностями при попытке найти тот или 
иной нужный ему модуль. Одной из причин большого размера библиотеки 
может стать многократная реализация того или иного класса, имеющая каж¬ 
дая свою семантику. Если примерная цена (обычно завышенная) нахождения 
определенной компоненты выше, чем примерная цена (обычно заниженная) 
создания заново такой компоненты, тогда любую надежду на ее повторное 
использование можно считать потерянной. Поэтому хорошо иметь хотя бы 
самый примитивный библиотекарь, позволяющий разработчику сортировать 
классы и модули по определенному принципу и добавлять в библиотеку по¬ 
лезные классы и модули по мере их создания. 

Организационные факторы. Чтобы создать мощный инструмент разра¬ 
ботки программного обеспечения, в его структуру должны быть включены 
библиотекарь и инструментальный редактор. Задачей библиотекаря является 
организация библиотеки классов проекта. Если не прилагать активных уси¬ 
лий, такая библиотека может стать громадной свалкой всякого барахла — 
ненужных классов, в которых неохота копаться ни одному из разработчиков. 
Часто также необходимо подтолкнуть людей к более активному использова¬ 
нию уже существующих наработок, а библиотекарь может облегчить процесс 
повторного использования, рассортировав в удобном порядке результаты те¬ 
кущего проекта. Задача инструментального редактора — создание проблемно- 
ориентированных и модернизация существующих инструментов под опреде¬ 
ленный проект. В процессе работы, например, могут потребоваться инстру¬ 
менты типа заменителя ввода-вывода для тестирования пользовательского 
интерфейса или своего собственного словаря классов. Инструментальный ре¬ 
дактор наилучшим образом сможет помочь при создании подобных вещей, 
составляя их, как правило, из существующих модулей, принадлежащих биб¬ 
лиотеке классов. Затем эти инструменты можно также использовать и в 
других проектах. 



199 


Менеджер, который уже сталкивался с проблемой ограниченности люд¬ 
ских ресурсов, может посетовать на то, что подобные мощные инструменты, 
а также библиотекарь и инструментальный редактор — непозволительная 
роскошь для них. Мы не отрицаем, такова реальность, когда дело касается 
некоторых проектов с ограниченными ресурсами. Однако оказывается, что во 
многих проектах работы в этом направлении ведутся, правда, обычно они 
рассматриваются как некий «довесок» к основной работе. Мы придерживаем¬ 
ся той точки зрения, что те прямые финансовые вложения в людей и в со¬ 
ответствующий инструментарий, которые придают подобной дополнительной 
деятельности более целенаправленный характер и повышают ее эффектив¬ 
ность, в конце концов окупаются. 

7.3. ДОСТОИНСТВА И НЕДОСТАТКИ ОБЪЕКТНО- 
ОРИЕНТИРОВАННОГО ПРОЕКТИРОВАНИЯ 
Достоинства объектно-ориентированного проектирования 

Новые технологии, и в частности объектно-ориентированную техноло¬ 
гию, обычно выбирают по одной или по двум причинам. Во-первых, из-за 
желания вырваться вперед на рынке (за счет меньшего времени разработки, 
большей гибкости продукта, или лучшей предсказуемости хода работ) с по¬ 
мощью новых технических средств, обеспечивающих громадный финансовый 
эффект. Во-вторых, столкнувшись со сложными проблемами, решить которые 
можно, по-видимому, лишь обратившись к новым технологиям. И если пер¬ 
вые пользователи новых технологий произнесут затем достаточное количест¬ 
во хвалебных слов в их адрес, то и другие, менее склонные к риску орга¬ 
низации последуют примеру первооткрывателей. 

Объектно-ориентированное проектирование не является новой техноло¬ 
гией, но в то же время она не является и достаточно привычной в основ¬ 
ном из-за того, что гораздо меньшее количество людей имеют опыт работы 
с ней, чем, например, со структурным проектированием. Мы, естественно, 
ожидаем, что ситуация постепенно изменится. Тем временем все большее 
количество людей уже слышало об успехах первых разработчиков, взявших 
на вооружение этот метод. Но, честно говоря, мы понимаем, что люди дол¬ 
жны «на своей шкуре» убедиться в способности метода решить задачу раз¬ 
работки сложной программной системы. А пока вам придется принять на 
веру то, что при использовании объектно-ориентированного подхода можно 
добиться значительных результатов. 

В гл. 2 мы показали, что использование объектной модели ведет к со¬ 
зданию комплексов, имеющих все свойства хорошо структуированных слож¬ 
ных систем. Объектная модель создает умозрительную схему объектно-ориен¬ 
тированного проекта и, таким образом, все ее преимущества связаны с 
объектно-ориентированным методом. Мы также назвали следующие преиму¬ 
щества применения объектной модели (и, таким образом, объектно-ориенти¬ 
рованного проектирования): 

* Использование выразительных средств объектных и объектно-ориентирован¬ 
ных программных языков. 

* Поддержка повторного использования отдельных составляющих программ¬ 
ного обеспечения. 

* Создание более открытых систем. 

* Снижение риска при разработке. 

* Активизация познавательных способностей человека. 
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Дополнительное осмысление этих преимуществ приводит к новым выво¬ 
дам; в частности, они указывают на то, что объектно-ориентированный под¬ 
ход может уменьшить время разработки и конечный размер исходных тек¬ 
стов. 

Пока еще нет достаточного количества примеров для оценки эффектив¬ 
ности объектно-ориентированного программирования при разработке формаль¬ 
ных экономических моделей типа СоСоМо или Price-S. 

Недостатки объектно-ориентированного проектирования 

Недостатки объектно-ориентированного проектирования могут повлиять 
на: 

* Характеристики системы. 

* Начальные затраты. 

Ухудшение характеристик. Существует определенная плата за посылку 
сообщения от одного объекта к другому, выражающаяся в некотором ухуд¬ 
шении быстродействия. Как мы говорили в гл. 3, для тех обращений к ме¬ 
тодам, которые не могут быть реализованы статически, необходимо провести 
динамический поиск, чтобы найти соответствующий метод, определенный в 
классе, которому принадлежит объект, получающий сообщение. Опыт пока¬ 
зывает, что обращение к методу может занимать в 1,75-2,5 раза больше 
времени, чем обращение к обычной подпрограмме [29, 30]. Но что значит 
«не могут быть реализованы статически»? Как правило, динамический поиск 
оказывается нужен, примерно, в 20% случаев от общего числа обращений. 
Поэтому транслятор в хорошо типизированном языке часто может сам опре¬ 
делить какие вызовы могут быть статически реализованы, и написать код 
вызова подпрограммы, а не поиска метода. 

Другой недостаток связан главным образом даже не с особенностями 
объектных и объектно-ориентированных языков, а со способами их примене¬ 
ния в контексте объектно-ориентированного проектирования. Мы много раз 
говорили, что объектно-ориентированное проектирование приводит к созда¬ 
нию систем, составленных из абстракций разных уровней. Особенностью та¬ 
кой структуры является сравнительно небольшой размер отдельных методов, 
так как они в свою очередь составлены из методов, соответствующих более 
низким уровням абстракций. Другая особенность такого разбиения на уровни 
— необходимость создания отдельных методов для достижения доступа к за¬ 
щищенным переменным объекта. Многочисленность методов ведет к излиш¬ 
нему количеству вызовов. Вызов метода высокого уровня абстракции обычно 
приводит к тому, что по системе проходит каскад вызовов; методы высоких 
уровней вызывают методы более низких и т.д. Для программ, в которых 
время является ограничивающим фактором, большое число вызовов может 
оказаться неприемлемым. Но, с другой стороны, такое разбиение на уровни 
необходимо для понимания системы; во многих случаях просто невозможно 
создать сложную систему, не прибегнув к разбиению на уровни. Мы реко¬ 
мендуем сначала получить нормальное функционирование, а затем опреде¬ 
лить уже в работающей системе те места, в которых существует опасность 
временного запаздывания. Впоследствии в систему можно внести 
соответствующие исправления, переопределив некоторые методы как встроен¬ 
ные (увеличив, таким образом, быстродействие за счет увеличения объема 
программы), сняв защиту с некоторых переменных или в крайнем случае, 
переделав объект в обычную запись вместо реализации класса. 



Подобное ухудшение характеристик связано с вложенностью классов: 
класс, находящийся на самом конце линии наследования может иметь мно¬ 
жество суперклассов, коды которых должны быть присоединены .при 
редактировании этого отдельного класса. Для небольших проектов можно по¬ 
советовать в данном случае не использовать глубокие иерархии классов, так 
как для этого потребуется присоединять слишком большое число объектных 
кодов. Проблему можно частично решить, используя такие транслятор и 
редактор связей, которые удаляют ненужные коды. 

Следующий недостаток, связанный с применением объектных и объект¬ 
но-ориентированных программных языков, вытекает из особенностей структу¬ 
ры выполняемых прикладных программ. Большинство трансляторов размеща¬ 
ют объектные коды по сегментам, причем коды каждой программной едини¬ 
цы (обычно это файл) размещаются в одном или в нескольких сегментах. 
Такая модель предполагает высокую степень локальности вызовов: програм¬ 
мы внутри одного сегмента вызывают подпрограммы из того же сегмента. 
Однако в объектно-ориентированных системах редко можно добиться подо¬ 
бной локальности ссылок. В больших системах разные классы, как правило, 
бывают объявлены в разных файлах и, так как методы каждого класса 
обычно строятся с помощью методов, принадлежащих другим классам, вызов 
одного метода обычно требует привлечения содержания многих сегментов. 
Это нарушает предположения, заложенные в компьютеры и касающиеся син¬ 
хронизации работы программ (особенно для систем с виртуальной памятью). 
Но, с другой стороны, мы ведь специально решили разделить проектные ре¬ 
шения на локальные и физические. Если система выходит из строя в про¬ 
цессе работы из-за слишком интенсивного обмена сегментами, то решение 
проблемы можно найти, изменив физическое расположение классов и разме¬ 
стив их по другим модулям. При этом мы изменим физическую модель сис¬ 
темы, что не окажет влияния на ее логическую модель. 

Наконец, последний возможный недостаток объектно-ориентированных 
систем связан с динамическим размещением и уничтожением объектов. По¬ 
добное размещение отличается от статического, осуществляемого либо гло¬ 
бально, либо внутри стека. Для многих типов систем динамическое разме¬ 
щение не вызывает трудностей, но для задач с ограниченным ресурсом вре¬ 
мени мы часто не можем выделить достаточного времени для завершения 
всех циклов, необходимых для динамического размещения. Существует про¬ 
стое решение этой проблемы: мы рекомендуем завершать динамическое со¬ 
здание таких объектов как часть создания программы, а не во время выпол¬ 
нения алгоритмов с ограниченным ресурсом времени. 

Тем не менее достоинства объектно-ориентированных систем, как 
правило, перевешивают все перечисленные недостатки. Руссо и Каплан, на¬ 
пример, сообщают, что быстродействие программы, написанной на C++, ча¬ 
сто выше, чем у аналогичной программы с теми же функциональными воз¬ 
можностями, написанной на языке Си [31 ]. Они полагают, что это связано 
с использованием виртуальных функций, которые в некоторых случаях уст¬ 
раняют необходимость прямой проверки типов данных и структур. Опыт 
также показывает, что размер исполняющих модулей объектно-ориентирован¬ 
ных систем обычно меньше, чем у функционально эквивалентных им сис¬ 
тем, созданных с помощью традиционных методов. 

Начальные затраты. Для некоторых проектов начальные затраты, свя¬ 
занные с внедрением объектно-ориентированного подхода, могут оказаться 
достаточно высокими. Использование любой подобной технологии требует 
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вложения капиталов в инструменты для разработки программного обеспече¬ 
ния. Кроме того, если организация-разработчик впервые использует тот или 
иной объектный или объектно-ориентированный программный язык, обычно 
отсутствуют необходимые проблемно-ориентированные библиотеки. Им прихо¬ 
дится либо начинать все с нуля, либо как-то стараться соединить имеющие¬ 
ся необьектно-ориентированные модули с объектно-ориентированными. Нако¬ 
нец, первый опыт использования объектно-ориентированного подхода обречен 
на неудачу без соответствующего предварительного обучения. Объектный, 
объектно-ориентированный язык программирования — это не просто «еще 
один язык программирования», который можно изучить на трехдневных кур¬ 
сах или прочитав одну книжку. Требуется время для выработки правильного 
понимания предмета объектно-ориентированного проектирования, причем со¬ 
ответствующий тип мышления должен быть принят и разработчиками, и ме¬ 
неджерами. 

Переход к объектно-ориентированному проектированию 

Изменение способа мышления является важным моментом. Кемпф, на¬ 
пример, считает, что «изучение объектно-ориентированного программирования 
может оказаться гораздо более трудной задачей, чем изучение «просто» оче¬ 
редного языка программирования. Причиной тому является скорее различие 
в стилях программирования, чем отличие синтаксисов при сохранении самой 
структуры языка. В данном случае приходится иметь дело не с новым язы¬ 
ком, а с новым типом мышления» [32]. 

Так как же перейти к объектно-ориентированному типу мышления? Мы 
рекомендуем следующее: 

* Обеспечить соответствующее обучение разработчиков и менеджеров. 

* Сначала использовать объектно-ориентированный подход при разработке 
наименее рискованных проектов и заставить разработчиков не бояться со¬ 
вершать при этом ошибки; использовать затем тех, кто работал в этой 
группе в качестве инициаторов новых проектов и экспертов в области 
объектно-ориентированного подхода. 

* Знакомить разработчиков и менеджеров с примерами хорошо структуриро¬ 
ванных объектно-ориентированных систем. 

Хорошим новым проектом может стать создание какого-либо инструмен¬ 
та разработки программного обеспечения или проблемно-ориентированных 
библиотек классов, которые затем могут быть использованы в других проек¬ 
тах. Наш опыт показывает, что разработчику-профессионалу требуется всего 
несколько недель чтобы овладеть синтаксисом и сематикой нового языка. 
Чтобы начать понимать важность и полезность понятий класса и объекта, 
тому же разработчику понадобится дополнительно еще несколько недель. Но 
чтобы стать квалифицированным проектировщиком классов, разработчику, 
возможно, придется потратить целых шесть месяцев. И это не всегда плохо, 
ведь в любой дисциплине требуется время, чтобы овладеть всем ее искусст¬ 
вом. 

Мы считаем, что обучение на примерах часто является наиболее эф¬ 
фективным из всех подходов. Если организация накопила некоторую крити¬ 
ческую массу различных примеров применения объектно ориентированного 
подхода, привлечение новых разработчиков и менеджеров и обучение их 
объектно-ориентированному проектированию становится гораздо более 
простым делом. Разработчики начинают с создания программ, в которых они 
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используют уже готовые, хорошо организованные абстракции. С течением 
времени те разработчики, которые хорошо разобрались и активно использо¬ 
вали эти компоненты программного обеспечения под наблюдением более 
опытных специалистов, набираются достаточного опыта, чтобы самостоятель¬ 
но начать разработку сложных концептуальных структур для объектных мо¬ 
дулей и стать, таким образом, проектировщиками классов. Рассмотрим те¬ 
перь некоторые примеры в гл. 8-12, иллюстрирующие практическое приме¬ 
нение объектно-ориентированного проектирования, реализованные с использо¬ 
ванием различных языков и затрагивающие независимые друг от друга 
предметные области. 

Заключение 

* Цикл разработки программного обеспечения с использованием объектно- 
ориентированного проектирования представляет собой последовательный 
итеративный процесс создания системы. 

* Структурный анализ является привлекательным инструментом создания ис¬ 
ходного продукта для объектно-ориентированного проектирования, однако 
объектно-ориентированный анализ оказывается еще более эффективным 
инструментом. 

* Проектирование можно начинать, если существует (возможно неполная) 
формальная или неформальная модель решения задачи; оно заканчивается 
там, где на первый план начинают выходить вопросы конпоновки систе¬ 
мы, а не разложения ее на составляющие. 

* В объектно-ориентированном проектировании невозможен «большой интег¬ 
рационный скачок» (сборка системы за короткое время из разрозненных 
элементов).” 

* В процессе эволюции системы предусмотрено несколько переходов ее в 
новое качество; каждое такое изменение требует различных затрат. 

* Использование объектно-ориентированного проектирования меняет практику 
управления и, в частности, затрагивает вопросы подбора кадров, этапно- 
сти, выпуска продукта и его дальнейших версий, контроля качества и ин¬ 
струментальной поддержки. 

* Объектно-ориентированное проектирование имеет много достоинств и неко¬ 
торые недостатки; опыт показывает, что достоинства метода намного пре¬ 
восходят его недостатки. 

* Организационный переход к использованию объектно-ориентированного 
проектирования требует изменения самого типа мышления; изучение объ¬ 
ектного или объектно-ориентированного языка представляет собой нечто 
большее, чем изучение «еще одного языка программирования». 

Дополнительная литература 

Использование методов структурного анализа в предварительной работе перед использова¬ 
нием объектно-ориентированного проектирования описано в работах Alabios [F, 1988]) и Stark 
[F, 1986]). Использование с той же целью методов объектно-ориентированного анализа описано 
в работах ВаШп и Moore [В, 1987], Gemosek, Monterio и Pribyl [В, 1987], Dahl [В, 1987], 
Mellor, Hecht, Tryon и Smith [В, 1987]. Работа Aron [Н, 1974]) представляет собой обстоятель¬ 
ный обзор проблем управления как программистом, так и командой программистов. Для настоя¬ 
щего понимания того, что происходит при разработке сложных систем, когда прагматические 
соображения заставляют забыть о теории, ознакомтесь с работами Glass [G, 1982], Lammers 
[Н, 1986] и Humphrey [Н, 1989]. Кроме того, DeMarco и Lister [Н, 1987] и Yourdon 
[Н, 1989] предлагают ряд очень полезных рекомендаций менеджеру, под руководством которого 
ведется разработка сложных программных систем. Предложения по тому, как перевести отдель¬ 
ных специалистов или целые организации на использование объектных моделей, можно найти в 
книгах: Goldberg [С, 1987], Goldberg и Kay [G, 1977] и Kempf [G, 1987]. Работа Vonk 
[Н, 1990] представляет собой обстоятельный учебник по прототипированию. 


Сборка системы за короткое время из разрозненных элементов. — Прим, перев. 
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ПРИМЕНЕНИЯ 

Создание какой-либо теории подразумевает наличие 
достаточных знаний об основных сторонах изучаемого пред¬ 
мета. Что касается проблемы компьютеризации, то таких 
знаний у нас недостаточно, и мы не имеем возможности 
подойти к предмету абстрактно. 

В этой ситуации нам не остается ничего другого, как 
внимательно изучать отдельные, хорошо понимаемые прак¬ 
тические примеры, чтобы на основе результатов перейти к 
рассмотрению более общих принципов. 


Марвин Мински (Marvin Minsky) 
«Форма и содержание компьютерной науки» 

Глава 8 

Smalltalk. Система домашнего 
отопления 

С точки зрения инженера, даже самая стройная теория является беспо¬ 
лезной, если она не отвечает на вопрос о том, как практически создавать 
системы для решения реальных задач. В данной части книги рассматривают¬ 
ся практические приемы создания программных систем на основе методоло¬ 
гии OOD, приведены примеры того, как от исходных требований к той или 
другой системе на основе использования терминологии, обозначений и про¬ 
цедуры 0OD осуществляется переход к реализации данной системы. В каче¬ 
стве примеров выбраны задачи из различных предметных областей. Каждая 
задача имеет собственную специфику и присущие только ей проблемы. В 
каждом примере используется свой язык программирования, чтобы проиллю¬ 
стрировать применимость методологии OOD для всего спектра объектных и 
объектно-ориентированных языков. В данной главе использован язык 
Smalltalk. Поскольку главным предметом нашего рассмотрения является про¬ 
цесс проектирования, а не программирования, тексты программ несколько 
сокращены. Однако основные детали перехода от проекта к его реализации 
и особенности использования конкретного языка программирования приведе¬ 
ны достаточно подробно. 

8.1. АНАЛИЗ 

Определение границ предметной области 

Приведенный выше текст содержит основные требования к системе 
отопления. При чтении этих требований можно задать следующие вопросы: 
Нужно ли моделировать процесс передачи тепла через стены дома? Есть ли 
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Требования к системе домашнего отопления 

Изложенные ниже требования к системе были первоначально сфор¬ 
мулированы Уайтом [1], а затем уточнены Кертом [2]. Блок-схема сис¬ 
темы отопления показана на рис. 8-1. Основная функция рассматривае¬ 
мой системы состоит в регулировании теплового потока в каждой из ком¬ 
нат дома для поддержания требуемой рабочей температуры tw. Рабочая 
температура для каждой комнаты вычисляется исходя из заданной желае¬ 
мой температуры td (которую пользователь задает через систему ввода) с 
учетом наличия в той или иной комнате людей. Если в какой-либо ком¬ 
нате люди отсутствуют, температура в ней поддерживается на 5° (по 
Фаренгейту) ниже желаемой. Кроме того, система хранит информацию о 
недельном цикле использования комнат и за 30 мин до ожидаемого появ¬ 
ления в конкретной комнате людей начинает повышать в ней температу¬ 
ру до нужного уровня. Если в течение двух недель подряд установлен¬ 
ный ранее цикл работы нарушается, система корректирует свой график. 
В каждой комнате дома имеются датчик для измерения температуры и 
инфракрасный датчик для непрерывного определения присутствия в ком¬ 
нате людей. Для управления системой и контроля за ее работой исполь¬ 
зуется специальный интерфейс пользователя, который позволяет вводить 
следующие команды: 

* Включение обогревателя Переключатель, позволяющий включать и 

отключать обогреватель системы 

* Установка желаемой Устройство для установки желаемой темпе- 

температуры ратуры (в каждой комнате) 



Рис. 8-1. Блок-схема системы отопления. 
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Применен 


* Переключатель-инди- Комбинированный переключатель-индикатор, 

катор перезапуска при позволяющий пользователю перезапустить сис- 

сбое тему после сбоя 

В системе имеются также средства индикации: 

* Индикатор состояния Служит для индикации состояния системы 

обогрева (функционирует/не функционирует) 

* Переключатель-инди- Комбинированный переключатель-индикатор, 

катор перезапуска при который автоматически выключается при обна- 
сбое ружении сбоя в подаче топлива или в работе 

камеры сгорания 

Непрерывный отсчет текущего времени с дискретностью в 1 с обес¬ 
печивает таймер. Перенос тепла осуществляется с помощью циркуляции 
горячей воды, нагреваемой в обогревателе. В каждой комнате имеется 
специальный клапан для регулирования подачи нагретой воды, который 
может быть дистанционно закрыт или открыт (полностью). Обогреватель 
состоит из котла, клапана для подачи топлива, воспламенителя, вентиля¬ 
тора и датчика температуры воды. Нагреваемая в котле вода циркулиру¬ 
ет по комнатам через управляемые клапаны. Обогреватель может нахо¬ 
диться либо в активном, либо в пассивном состоянии (выключаться) в 
зависимости от потребности в тепле. Процедура включения обогревателя 
выполняется в следующем порядке: 

* включается двигатель вентилятора; 

* система контролирует обороты двигателя и при достижении заданной 
величины (об/мин) открывается топливный клапан и зажигается топ¬ 
ливо; 

* при достижении заданной температуры воды в котле открываются кла¬ 
паны подачи воды в комнаты; 

* включается индикатор состояния работы обогревателя. 

Включение выполняется в следующем порядке: 

* закрывается клапан подачи топлива и через 5 с останавливается двига¬ 
тель вентилятора; 

* отключается индикатор состояния; 

* закрываются все клапаны подачи воды в комнатах. 

Работа обогревателя контролируется датчиком подачи топлива и оп¬ 
тическим датчиком камеры сгорания. При обнаружении каких-либо от¬ 
клонений выполняется выключение обогревателя: выключается переключа¬ 
тель-индикатор и закрываются все клапаны подачи воды. Для определе¬ 
ния неообходимого количества тепла и управления его подачей в комна¬ 
ты служит регулятор теплового потока, взаимодействующий с другими 
компонентами системы. Регулятор теплового потока управляет процессом 
поддержания рабочей температуры и графиком ее изменения независимо 
от работы обогревателя. Если температура в каком-либо помещении опу¬ 
скается на два градуса ниже требуемой или поднимается на два градуса 
выше требуемой, то формируется команда на подачу или прекращение 
подачи тепла в это помещение. При включенных переключателях (обог¬ 
ревателя и перезапуска) и необходимости подачи тепла в какую-либо 
комнату производится включение обогревателя (если она была 
выключена). Если потребность в подаче тепла исчезает, обогреватель 
выключается. То же происходит при отключении любого из двух пере¬ 
ключателей. Повторное включение обогревателя после остановки не мо¬ 
жет быть выполнено ранее чем через 5 мин. 
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какие-либо требования по безопасности, связанные с наличием высоких тем¬ 
ператур? Что нужно делать в случае неисправности клапанов подачи воды 
или датчиков температуры? Мы стараемся сопоставить решаемую задачу с 
другими аналогичными задачами, для которых уже существует решение. На¬ 
пример, можно отметить, что система домашнего отопления напоминает сис¬ 
тему тепличного хозяйства (гл. 5), но существенно отличается от системы 
регулирования (гл. 7). В результате у нас имеются все основания заклю¬ 
чить, что система отопления относится к категории задач управления про¬ 
цессом, но не к категориям баз данных или научного эксперимента, хотя 
элементы двух последних в нашей задаче тоже присутствуют. 

Уточнение требований. Внимательно прочитав требования, мы можем 
обнаружить, что они являются неполными, излишне подробными и внутрен¬ 
не противоречивы. В то же время эти требования реальны, не выдуманы. 
Даже если мы будем иметь исчерпывающую информацию о поставленной 
проблеме, мы не сможем в полной мере использовать эти знания из-за не¬ 
совершенства наших инструментальных средств. Сказанное выше не является 
критикой каких-либо конкретных требований, это только подтверждение из¬ 
вестного факта, основанного на практическом опыте: при выполнении проек¬ 
та всегда приходится мириться с определенными неясностями. 

Что касается неполноты изложенных требований к системе, то можно 
привести несколько конкретных примеров. В частности, не указан масштаб 
системы отопления: контроль температуры может вестись и в 10, и в 
10 000 комнат. Является ли используемое оборудование одно- или многопро¬ 
цессорным? Если процессор один, то насколько мы ограничены ресурсами 
памяти и производительности? Для простоты предположим, что системные 
проектировщики установили требование по реализации программной поддер¬ 
жки на основе одного процессора и его ресурсы достаточны для управления 
системой при заданном числе комнат. Разумеется, желательно спроектиро¬ 
вать систему так, чтобы она легко адаптировалась к любому числу комнат 
при минимуме вносимых изменений. 

В требованиях не говорят о том, как система должна реагировать на 
параллельные события, когда люди появляются одновременно в двух комна¬ 
тах. Система домашнего отопления не относится к числу задач с жесткими 
ограничениями при работе в реальном времени, в требованиях определены 
критические интервалы времени в несколько секунд, но не милли- и не 
микросекунд. Можно предположить альтернативные подходы к проекту с 
различным распределением ресурсов памяти и времени. Для создания иллю¬ 
зии параллелизма при наличии одного процессора необходимо обеспечить 
время реакции на события в пределах зрительной реакции человека. Если 
мы предпочитаем систему, управляемую событиями, необходимо обеспечить 
работу процессора в режиме прерываний по сигналам аппаратных средств. 
Однако на данном этапе нет срочной необходимости делать подобный выбор, 
его можно отложить до того момента, когда будет более полная информа¬ 
ция, чтобы взвесить каждое решение. Излишне подробно изложены требова¬ 
ния к регулятору потоков тепла. В частности, определено, что он отслежи¬ 
вает недельный график использования комнат. Полезность функции отслежи¬ 
вания графика сомнений не вызывает, но непонятно почему эту функцию 
должен выполнять регулятор. Предъявляемые исходные требования не долж¬ 
ны в общем случае затрагивать особенности проектирования, поскольку это 
ограничивает свободу программиста, заставляет отказываться от более опти¬ 
мальных вариантов, которые могут упростить решение всей задачи. Будем 
рассматривать предъявленное к регулятору требование в свободной интерпре- 
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тации и условимся, что главное — обеспечить функцию отслеживания не¬ 
дельного графика. Механизм реализации этой функции может отличаться от 
изложенного в требованиях. 

Наличие в требованиях противоречий также не вызывает особого удив¬ 
ления: чем сложнее система, тем вероятнее в ней столкновение различных 
требований. Изложенные нами требования в этом смысле не являются иск¬ 
лючением. Проанализируем внимательно требования к переключателю-инди- . 
катору сбоев. С одной стороны, установлено, что он автоматически отключа¬ 
ется при сбое в подаче топлива или в камере сгорания. С другой стороны, 
утверждается, что отдельные датчики могут передавать в систему сигналы 
об отклонениях, ведущих к выключению обогревателя, выключению пере¬ 
ключателя-индикатора и закрытию клапанов. В первом случае, таким обра¬ 
зом, говорится о непосредственном отключении переключателя-индикатора, а 
во втором сначала выключается обогреватель и лишь затем отключается пе¬ 
реключатель-индикатор. Приходится выбирать, на каком варианте поведения 
системы остановиться. Если предположить, что предварительного выключения 
обогревателя не требуется, то оператор будет оповещен о неисправности сра¬ 
зу при ее обнаружении, а выключение обогревателя задержатся во времени. 
В другом варианте информация о неисправности будет задержана, но 
обогреватель выключается сразу. Чтобы разобраться в такой ситуации, луч¬ 
ше всего спросить мнение пользователя или показать пользователю альтер¬ 
нативные прототипы и предложить сделать выбор. Поскольку важнее чаще 
всего безопасность системы, остановимся на варианте с немедленным 
выключением обогревателя. 

Формирование словаря предметной области. Так как ни проектиров¬ 
щик, ни пользователь не могут заранее иметь полное представление о всех 
подробностях поведения системы, следует воспользоваться методом последова¬ 
тельного приближения. Мы будем создавать варианты прототипов системы на 
языке Smalltalk и демонстрировать их работу заказчику. Когда мы достигнем 
согласия (возможно, изменив при этом некоторые требования), то модифи¬ 
цируем систему в части обеспечения интерфейса с внешним оборудованием 
(датчиками, клапанами), сохранив ее принципиальную основу. 

Теперь полезно зафиксировать наиболее существенные факты относи¬ 
тельно предметной области. На основе структурного анализа мы в первую 
очередь создадим эскиз диаграммы связей и в соответствии с ней диаграмму 
потоков данных самого верхнего уровня. Более подробно структурный анализ 
рассматривается в гл. 10, поскольку для решаемой в данной главе задачи 
исходные требования достаточно хорошо определены, а сама задача относи¬ 
тельно статична. Кроме того, все мы являемся в определенной степени спе¬ 
циалистами по данной предметной области: в наших домах и по месту ра¬ 
боты существуют те или другие отопительные системы. 

Мы назвали текущий этап анализом, но на самом деле это уже начало 
последовательно-возвратного проектирования. В гл. 7 было показано, что 
объектно-ориентированная методология имеет достаточно хорошую систему 
документирования знаний о ключевых абстракциях предметной области. 

На рис. 8-2 показана схема объектов, отражающая верхний уровень 
структуры системы. На схеме отражено наличие в системе множества объек¬ 
тов, упомянутых выше при рассмотрении требований к системе: комнаты, 
регулятор, обогреватель и интерфейс пользователя. 

В требованиях указан только один вид интерфейса пользователя, а в 
действительности существуют две категории пользователей: люди, находящи¬ 
еся в комнатах, и операторы системы. По причинам, которые будут объяс- 
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Рис. 8-2. Схема объектов домашней отопительной системы. 

йены ниже, на верхнем уровне системы мы рассматриваем только интерфейс 
оператора. Обратим внимание, что на схеме показана только одна внешняя 
связь между объектами. Эта связь отражает поток тепла от печки в комна¬ 
ты для регулирования температуры. В системе существует обратная связь, 
находящаяся вне нашей предметной области. Мы не будем заботиться о на¬ 
личии других источников обогрева или охлаждения (например, камины или 
открытые окна). 

Другие отношения между объектами на схеме этого уровня не показа¬ 
ны, поскольку на текущем этапе анализа это преждевременно. Когда мы 
перейдем к процессу проектирования, данную схему необходимо изменить и 
указать большее количество подробностей, что позволит уточнить границы 
каждого объекта и принять оптимальные проектные решения. 

Мы уже отметили выше, что функция отслеживания недельного графи¬ 
ка обогрева является одной из основных в системе, но не обязательно долж¬ 
на выполняться регулятором. Зафиксируем это решение, приведя схему объ¬ 
ектов, означающих помещение дома (рис. 8-3). В каждом помещении име¬ 
ются клапан подачи воды, датчики измерения и задания температуры, дат¬ 
чик присутствия людей. Кроме того, для каждого помещения существует 
свой график посещения. Размещение данных о графике посещения в каждом 
объекте-помещении (а не концентрация их всех в регуляторе) объясняется 
тремя причинами. 

Во-первых, отнесение этих данных к регулятору приведет к тому, что 
при увеличении числа помещений придется корректировать эти данные и, 
следовательно, процесс развития системы усложняется. Во-вторых, сведения 
о графике посещения индивидуальны для каждой из комнат и размещение 
их в соответствующих объектах увеличивает общность абстракций. В-треть- 
их, принятое решение делает регулятор более автономным. Задача регулято¬ 
ра состоит лишь в том, чтобы управлять подачей тепла в помещение, а по¬ 
мещение «само» должно решить, нужно ли ему тепло в зависимости от 
того, находятся или ожидаются в нем люди (по собственному графику), а 
также с учетом разности между фактической и желаемой температурой. Так 
же как на предыдущей схеме, отношения между объектами на рис. 8-3 не 
показаны. На данном этапе эта информация опускается. 

14 Гради Буч 
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Рис. 8-3. Схема объектов-помещений. 

Анализ предметной области 

Теперь, имея в общих чертах модель создаваемой системы, можно пе¬ 
рейти к анализу предметной области, изложенному в гл. 4. 

Реальное состояние задачи. Исходя из требований к системе, мы 
выделили следующие ключевые абстракции: 

Система отопления Таймер Дом 

Помещение График посещения Датчик текущей 

температуры 

Датчик присутствия лю- Клапан подачи воды Датчик желаемой 

дей температуры 

Интерфейс оператора Выключатель отопления Переключатель-ин¬ 

дикатор повторного 
включения 

Индикатор работы печки Печка Датчик температу¬ 

ры в котле 

Клапан топлива Вентилятор Воспламенитель 

Регулятор подачи тепла 

Существует также абстракция температуры, но она не представляет со¬ 
бой реально осязаемый предмет, а является свойством, которое можно изме¬ 
рить и почувствовать. Температура, несомненно, является существенным 
элементом словаря предметной области. Установив, что температура в систе¬ 
ме измеряется в градусах по Фаренгейту, и вспомнив, что в системе ис¬ 
пользуется вода для переноса тепла, мы сможем сделать логичные предполо¬ 
жения относительно ожидаемого диапазона температуры. Вода не должна 
иметь температуру ниже точки замерзания и выше перегретого пара. 

Из числа объектов, указанных в требованиях, мы оставили в стороне 
пользователей системы. Люди рассматриваются в данном случае вне системы 
как посредники, являющиеся причиной ряда событий, регистрируемых систе¬ 
мой отопления. С точки зрения программы они никак не отражены. Однако 
заметим, что нас интересуют два вида пользователей: операторы системы и 
простые посетители помещений. Их отношение к системе принципиально 
различается: одни из них (посетители) управляют значением желаемой тем 
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пературы в комнатах, а другие (операторы) могут включать, выключать и 
перезапускать систему. Исходя из этого, интерфейс оператора следует отне¬ 
сти к абстракциям верхнего уровня, отделив его от интерфейса обычных по¬ 
сетителей. 

События. Перечислим теперь внешние события, на которые система 
отопления должна реагировать: 

* Посетитель изменил значение желаемой температуры. 

* Посетитель вошел в помещение или вышел из него. 

* Изменилась фактическая температура в помещении. 

* Неисправность в подаче топлива или в камере сгорания. 

* Оператор включил или выключил отопление. 

* Система отопления включена или отключена. 

* Оператор выполнил повторный запуск системы после сбоя. 

Все события асинхронны; определено только одно событие, совершаемое 
периодически: 

* Сигнал таймера с интервалом в 1 с. 

Это событие не является внешним, но с ним связано управление венти¬ 
лятором и котлом. 

Перечислив эти события, мы можем сопоставить их с ключевыми абст¬ 
ракциями, определив тем самым границы системы. Можно, например, пред¬ 
положить, что за временем следит таймер, а такие компоненты, как график 
посещения, только реагируют на сигналы таймера. Выявление внешних со¬ 
бытий позволяет также уточнить, что система делать не может. В частно¬ 
сти, у нас нет средств обнаружения отказов клапанов подачи воды и, следо¬ 
вательно, система не может реагировать на такие неисправности. 

Перечень внешних событий помогает контролировать полноту списка 
ключевых абстракций: должна существовать хотя бы одна абстракция, свя¬ 
занная с каждым событием. Например, отметим, что в исходном списке 
ключевых абстракций нет объектов, позволяющих обнаруживать отклонения 
в подаче топлива и в работе камеры сгорания. Это заставляет дополнить 
список еще двумя ключевыми абстракциями: датчиком неисправности подачи 
топлива и датчиком сбоя в камере сгорания. 

Документирование ключевых абстракций. Перечисление ключевых абст¬ 
ракций предметной области очень полезно, но в большинстве случаев, кроме 
самых простых, явно недостаточно. В гл. 7 уже говорилось о том, что очень 
важно отразить системные решения в объектно-ориентированной форме. Для 
каждой выявленной нами ключевой абстракции необходимо документально 
зафиксировать ее входные/выходные характеристики и поведение. Примени¬ 
тельно к таймеру это может быть изложено следующим образом: 

* Импортирует (получает) Сообщение о прохождении интервала времени 

в 1 с, получаемое извне. 

* Экспортирует (передает) Действительное значение времени в секундах 

с момента включения системы. 

* Поведение Передаваемое значение увеличивается на 1 с 

независимо от состояния обогревателя (актив¬ 
ен/пассивен). 

Важно также документировать имеющиеся в отношении каждой абстрак¬ 
ции предположения. Для таймера можно записать следующее: 
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* Предположение Диапазон значений таймера заведомо доста¬ 

точен, чтобы избежать переполнения. Напри¬ 
мер, 32-разрядный таймер может действовать 
без переполнения более 130 лет. 

Внимательный читатель может возразить, что такой способ документи¬ 
рования эквивалентен переписыванию исходных требований с сортировкой их 
по ключевым абстракциям. Конечно, нет необходимости переписывать все 
требования, предъявленные к большой системе, поскольку это долгая и уто¬ 
мительная работа. На практике целесообразно документировать таким спосо¬ 
бом только самые существенные абстракции. Кроме того, этот процесс ни¬ 
когда не происходит сразу, а ведется последовательно по мере выявления 
ключевых абстракций. Сначала обнаруживаются наиболее важные абстрак¬ 
ции в словаре эксперта по данной проблеме, затем делаются обобщения и 
выявляются компоненты абстракций. Таким образом, мы постепенно 
обнаруживаем имеющиеся в требованиях противоречия, уточняем терминоло¬ 
гию, устраняем неоднозначности и добираемся до логики поведения каждой 
ключевой абстракции. 

Создание прототипа 

В процессе анализа системы мы добились понимания ключевых абстрак¬ 
ций проблемы и главных функций системы. Теперь мы готовы приступить к 
поиску решений, которые удовлетворяли бы поставленным требованиям. На 
этой стадии очень важно найти компоненты, которые могут использоваться 
в программе многократно. Это позволит создавать' новые системы методом 
компоновки из блоков, а не начинать каждый раз заново. 

Повторное использование компонент. Активный поиск компонент, кото¬ 
рые могут затем использоваться в других задачах, составляет существенный 
этап проектирования. Этому процессу способствует наличие множества биб¬ 
лиотек классов, которые созданы для объектно-ориентированных языков про¬ 
граммирования. В частности, в библиотеке классов Smalltalk-80 есть такие 
компоненты, как StandardSystemView (их можно использовать в интерфейсе 
пользователя). В Smalltalk имеются классы для моделирования измеритель¬ 
ных приборов [3] и такие компоненты, как CircleMeterView и BarGange- 
WithScaleView, для моделирования аналоговых приборов (датчиков желаемой 
и фактической температуры). 

Эти классы независимы от предметной области и не могут быть ис¬ 
пользованы непосредственно. Их требуется дополнить так, чтобы они отра¬ 
жали словарь предметной области. По этой причине мы создадим специали¬ 
зированные классы на основе указанных. Осторожный проектировщик может 
подумать, что мы уже перешли к этапу реализации. Конечно, начиная 
создавать прототипы, нужно иметь ясный план, но нельзя избежать и оши¬ 
бок. Главная роль прототипов в нашей задаче состоит в определении того, 
удовлетворяет ли предложенный интерфейс пользователя поставленным усло¬ 
виям до начала окончательного проектирования. Если интерфейс нас 
удовлетворяет, мы включим его в перечень абстракций, составляющих систе¬ 
му, и не будем возвращаться к этой проблеме. На основе прототипов мы 
приходим к соглашению относительно интерфейса пользователя, рассмотрев, 
возможно, несколько вариантов. 
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Проектирование класса «переключатель». Рассмотрев перечень ключе¬ 
вых абстракций, мы находим целесообразным сделать обобщение для выклю¬ 
чателя отопления и переключателя-индикатора повторного пуска. В обоих 
случаях мы имеем дело с обычным переключателем. Выключатель отопления 
можно представить себе как два транспаранта (окна) с надписями «отопле¬ 
ние включено» (heat on) и «отопление выключено» (heat off), один из кото¬ 
рых должен быть «подсвечен». Для выбора между окнами можно использо¬ 
вать «мышь». При переключении «подсветка» окон меняется местами и пе¬ 
редается сообщение в программу об изменении состояния. Выбор «мышью» 
подсвеченного окна не вызывает никакой реакции. 

В библиотеке Smalltalk-80 можно найти класс BooleanView, который 
пригоден для нашей цели. Этот класс представляет так называемое подклю¬ 
чаемое окно, которое может «зажигаться» и «гаситься», и содержит средства 
индикации на дисплее и реагирование на «мышь». Для образования пере¬ 
ключателя нам достаточно два таких переключаемых окна, которые должны 
находиться в противоположных состояниях. 

Класс BooleanView нужно дополнить в соответствии с требованиями за¬ 
дачи и снабдить надписью. Новый экземпляр класса создадим с помощью 
следующего оператора: 

aBooleanView <— BooleaView 

on: aModel 

aspect: #state 

label: ’a label’ 

change: #state: 
value: true. 

Это общий прием для всех языков OOP (object-oriented programming), 
поддерживающих метаклассы: для образования экземпляра класса и его ини¬ 
циализации используется метод соответствующего метакласса. 

Класс BooleanView является примером рассмотренного в гл. 4 механизма 
МѴС (model-new-controller). По указанному выше методу создаем новый вид 
индикации и новый контроллер. Селектор on: указывает на необходимость 
активизации модели в случае попадания «мыши» в окно (с нажатием). Это 
позволяет увидеть роль модели: объект видит модель, а контроллер ее изме¬ 
няет. 

Реализация механизма МѴС не позволяет объектам быть полностью 
«видимыми» друг для друга. Контроллер и индикация взаимозависимы и мо¬ 
гут обмениваться сообщениями. Каждый из них может направлять сообще¬ 
ния в модель. Модель, напротив, не может прямо направлять сообщения 
контроллеру и индикатору. Взаимодействие модели и индикации осуществля¬ 
ется косвенно через механизм, изложенный в гл. 3 (каждый объект управ¬ 
ляет списком связанных с ним объектов). Поэтому появление нового объекта 
сопровождается изменением списка зависимостей. Индикация может быть 
связана только с одной моделью, а модель — с множеством индикаций. 

При нажатии на кнопку «мыши» контроллер посылает сообщение state: 
в модель с указанием булева значения нового состояния. Чтобы модель бы¬ 
ла полной, необходимо реализовать метод state: так, чтобы выполнить необ¬ 
ходимые действия. Класс BoolewanView называется подключаемым окном по¬ 
тому, что достаточно ввести это в программу, чтобы добиться необходимого 
эффекта. Такие окна имеют много общего с приемами, используемыми в 
языках CLU и Ada. 
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Для образования переключателя необходимо иметь два объекта 
BooleanView. Это лучше всего сделать путем агрегатирования, а не наследо¬ 
вания, создав класс ToggleSwitch (переключатель), использующий 
BooleanView. Другая причина, по которой использование предпочтительнее, 
состоит в том, что поведение переключателя является более вважным, чем 
поведение окна. Необходимо, чтобы два окна устанавливались в противопо¬ 
ложные состояния при переключениях. Остановимся на таком решении: со¬ 
здаем класс ToggleSwitch из суперкласса Object путем использования (вклю¬ 
чения) класса BooleanView. 

Класс ToggleSwitch также необходимо сделать подключаемым. Он не 
должен быть связан с конкретным содержанием надписи и конкретным спо¬ 
собом использования сигнала. Для этого в класс ToggleSwitch вводятся четы¬ 
ре селектора: для надписей во включенном и отключенном состоянии и для 
действий по включению и отключению. Из этого вытекает необходимость 
введения в этот класс следующих трех переменных: 

* State Состояние переключателя вкл./откл. 

* TrueAction Блок действий, выполняемых при включении 

* FalseAction Блок действий, выполняемых при отключении 

Кроме того, нужны еще две переменные, связанные с визуализацией 
состояния объекта: 

* trueView Объект класса BooleanView, представляющий включенное 

состояние 

* falseView Объект класса BooleanView, представляющий выключен¬ 

ное состояние 

Отсюда можно перечислить методы класса ToggleSwitch: 
initialize: initialValue 

true Label: firstLabel 

false Label: secondLabel 

trueAction: firstAction 

falseAction: secondAction 

«Initialize a toggle switch. InitialValue Is expected to be of the class Boolean. FirstLabel and 
secondLabel are expected to be of the class String. firstAction and secondAction are experted to 
be or the class Block.» 
state <— InitialValue. 
trueAction <— firstAction. 
falseAction <— secondAction. 
trueView <— BooleanView 
on: self 

aspect: #state 
label: firstLabel asText 

change: #state: 
value: true. , 

falseView <— BooleanView 
on: self 

aspect: #state 
label: secondLabel asText 

change: fstate: 
value: true. 
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Комментарий в примере документирует действие селекторов. Поскольку 
Smalltalk поддерживает механизм позднего связывания, из текста программы 
не всегда можно понять, к какому объекту относятся методы. Невниматель¬ 
ный программист может неверно воспользоваться методом. Метод будет реа¬ 
лизовываться непредсказуемым образом, пока не обнаружится ошибка ііри 
выполнении программы. Динамическое связывание является полезным 
свойством в определенных случаях, но требует большего внимания от про¬ 
граммиста. Для чего мы определили метод инициализации в классе 
ToggleSwitch, а не воспользовались методом метакласса, как делали раньше? 
Метод метакласса используется в том случае, когда мы одновременно созда¬ 
ем и инициализируем объект либо при инициализации объекта-переменной. 

Определение метода initialize в самом классе позволяет создать объект 
(с помощью методов new или new:, определенных в классе Behavior), ини¬ 
циализировать его, а позднее инициализировать тот же объект еще раз. Та¬ 
кой подход придает большую гибкость: объект ToggleSwitch можно переини- 
циализировать с другой надписью и другими операциями. При другом под¬ 
ходе придется вводить дополнительный метод для изменения состояния объ¬ 
екта. 

Метод state: имеет важное значение для реализации функций данного 
класса. Поскольку оба объекта BooleanView имеют общую модель, фиксируе¬ 
мые ими события обрабатывают одинаково. Сообщение state: посылается од¬ 
ним из контроллеров trueView или falseView в зависимости от того, какой 
из них зафиксировал нажатие «мыши». Метод state: должен, следовательно, 
изменить переменную state, означающую новое состояние объектов. После 
этого выполняются соответственно методы trueAction или falseAction. Опишем 
логику следующим образом: 

stale: aBoolean 

«Set the state of the toggle switch. aBoolean Is expected to be of the class boolean.» 

state-a Boolean 
IfFalse: 

[state <— aBoolean. 
self changed: #state. 
state 

IfTrue: 

[trueAction value] 

ifFalse: 

[falseAction value]) 

Осталось неясным только значение сообщения changed: в этом методе. 
В гл. 3 говорилось уже о том, что в языке Smalltalk используется механизм 
зависимостей для передачи объектам информации о наличии изменений 
(update:). В нашем случае сообщение update: направляется объектам 
trueView и falseView с аргументом #state. Поэтому оба объекта всегда знают 
о факте переключения состояния, хотя само переключение регистрируется 
только одним из них. Метод changed: можно было бы заменить следующими 
двумя операторами: 

trueView update: #state. 

falseView update: #state. 
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Рис. 8-4. Диаграмма объектов переключателя. 

Механизм использования метода changed: является более общим и поэ¬ 
тому предпочтительнее. Кроме того, для изменения поведения переключате¬ 
ля в этом случае (метод changed:) необходимо модифицировать только метод 
state:. Метод update: в классе BooleanView должен запросить текущее состоя¬ 
ние и «высветить» соответствующее окно. Поскольку объекты-переменные в 
Smalltalk непосредственно «невидимы» (имеет место ограничение доступа), 
для определения состояния используется селектор state: 


♦Return the state of the toggle switch.» 

~state 

Поведение объектов класса ToggleSwitch схематически показано на 
рис. 8-4. На этой схеме видны отношения между переключателем, соответ¬ 
ствующим окном и сигналом нажатия «мыши». 

Для контроллера переключатель «видим», так как является одним из 
его полей. Окна переключателя доступны по двум направлениям: через поля 
trueView и falseView, а также как связанные компоненты. Все связанные 
компоненты доступны через итератор соответствующего списка. 

На временной диаграмме поясняется процесс управления. При нажатии 
на «мышь» контроллер фиксирует событие по сообщению controlTerminate. 
Затем посылается сообщение state: в модель, а модель формирует сообщение 
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update: для обоих окон с помощью метода changed:. Каждое из окон отвеча¬ 
ет модели сообщением своего нового состояния. 

Для полноты определения в переключатель введены методы trueView и 
falseView, которые являются селекторами, возвращающими значения объек¬ 
тов-переменных. В качестве примера, напишем следующее определение: 

true View 

«Return the true view of the toggle switch.» 

^trueView 

Ниже показано использование этих селекторов для работы с окнами. 

Проектирование класса «выключатель отопления». Уточним структуру 
класса ToggleS witch, чтобы образовать класс «выключатель отопления» 
(HeatSwitch) . Поскольку мы имеем дело с разновидностью переключения, ис¬ 
пользуем механизм наследования в соответствии со схемой на рис. 8-5. 
Класс HeatSwitch образован наследованием класса ToggleSwitch, который 
содержит класс BooleanView. Строение класса Boolean View для простоты не 
показано, поскольку он используется в качестве примитива. 

Отметим также, что между классами установлены отношения старшин¬ 
ства. Класс ToggleSwitch является в нашем проекте абстрактным и отмечен 
уровнем 0 (ноль). Очевидно также, что в Smalltalk метакласс может быть 
реализован только в виде единственного класса — самого себя. Уровень 
классов HeatSwitch и BooleanView не показан, так как количество объектов 
может быть произвольным. 

Факт наследования класса HeatSwitch от ToggleSwitch в значительной 
степени уже определяет его поведение. Нам осталось только уточнить метод 
инициализации с образованием нужной надписи в окнах этого класса. Сде¬ 
лаем это следующим образом: 



Рис. 8-5. Диаграмма класса «переключатель». 
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initializeOnAction: firstAction offAclion: secondAction 
«Initialize the heat switch.» 
self 

Initialize: false 
trueLabel: ’heat on’ 
faiseUbel: ’heat off’ 
trueActlon: firstAction 
falseActlon: secondAction 

Мы не могли здесь воспользоваться переопределением метода инициали¬ 
зации ToggleSwitch из-за различного числа параметров. 

Проектирование класса «датчик желаемой температуры». По аналогии 
с переключателем введен еще один универсальный класс. Датчик можно 
представить себе в виде циферблата, созданного с помощью библиотечного 
класса CircleMeterView. Циферблат — более сложное устройство, чем окно 
BooleanView: пользователь может установить на нем нужное значение неко¬ 
торого аналогового параметра. Предположим, что проектируемый нами класс 
DesiredTemperatureSensor содержит переменную value, означающую выбран¬ 
ное значение температуры, и переменную-объект theView, изображающую 
циферблат. Опишем такой класс с использованием класса CircleMeterView. 

initialize 

«Initialize the desired-temperature sensor.» 

I analogGauge I 

super initialize. 

analogGauge <— CircleMeterView 
on: self 
aspect: «value 
change: «value 
range: (SO to: 90 by: 5). 

theView <— View new. 

theView 

addSubView: analogGauge 
in: (0 @ 0 extent: 1 @ 1) 
borderWidth: 0. 

value <— 65.0 
value: aValue 

«Set the value of the desired-temperature sensor.» 

value - aValue 
IfFalse: 

[value <— aValue. 

self changed: «value. 

self changed: «desiredTemperature] 

Приведенные методы повторяют структуру класса ToggleSwitch. Класс 
CircleMeterView является подключаемым. Это, в частности, означает необхо- 
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димость формирования сообщения в случае действия «мышью» в окне данно¬ 
го класса. Данную функцию решает метод value:, действие которого состоит 
в установлении нового значения желаемой температуіры (значение перемен¬ 
ной value). После этого активизируется метод changed:, сообщающий о на¬ 
личии изменений другим объектам. 

Отметим также, что изменение сопровождается посылкой значения 
#desired-Temperature всем объектам, находящимся в отношении зависимости. 
Внимательный читатель отметит, что эти действия избыточны; посылается 
также значение #value. Эти два посылаемых значения отображают различ¬ 
ные виды событий — внутренние и внешние. Для классов ToggleSwitch и 
Desired-TemperatureSensor сигналом о наличии изменений (для внутренних 
объектов BooleanView и CircleMeterView) является значение #value. Кроме 
того, нужно сообщить о наличии изменений и внешним объектам, которых 
эти изменения затрагивают, с помощью более информативного сигнала 
#desiredTemperature. Это аналогично использованию метода Changed: в клас¬ 
се ToggleSwitch для активизации блоков действий trueAction и falseAction в 
зависимости от вида событий. 

В процессе создания прототипов мы исправили одну ошибку в классе 
CircleMeterView, введя обратный знак для перемещения циферблата в другом 
направлении. Есть еще одна причина стабильности и устойчивости повторно 
используемых программных компонент. Обнаружение ошибок на стадии 
создания прототипов имеет положительный эффект, поскольку в наших ин¬ 
тересах обнаружить ошибки и слабые места как можно раньше, до того как 
появляются проектные решения, которые трудно исправить. 

Создание прототипов интерфейса пользователя. На рис. 8-6 приведен 
снимок с экрана дисплея при создании прототипов на языке Smalltalk ин¬ 
терфейсов оператора и посетителя с помощью классов ToggleSwitch и 
DesiredTemperatureSensor, а также двух аналогичных классов Indicator и 
CurrentTemperatureSensor. Каждое изображение состоит из комбинаций окон, 
создаваемых этими классами, объединенных вместе реализацией класса 
StandardSystemView. Интерфейс оператора включает два объекта ToggleSwitch 
и один Indicator. Интерфейс посетителя состоит из одного объекта 
DesiredTemperatureSensor, одного Indicator и одного CurrentTemperatureSensor 
(который в свою очередь использует класс BarGangeWithScaleView) . 

На этапе создания прототипов выявляется еще один существенный мо¬ 
мент: проблема взаимоисключений в интерфейсе пользователя. В частности, 
мы знаем из требований к системе, что внутреннее событие может управ¬ 
лять переключателем-индикатором, а оператор имеет возможность установить 
этот переключатель повторно. Если не установить специальных ограничений, 
оператор может вывести переключатель из строя. Следовательно, при нали¬ 
чии нескольких каналов управления мы должны обеспечить защиту от тако¬ 
го рода вмешательства. 

Подтверждается сделанное выше предположение о том, что в процессе 
проектирования следует постоянно следить за параллельными событиями. 
Наиболее распостраненным приемом управления простыми видами взаимо¬ 
исключений является использование семафора. Семафор устанавливается в 
критическом месте программы и позволяет использовать только один из ка¬ 
налов управления. В библиотеке Smalltalk-80 есть класс Semaphore, реализу¬ 
ющий такую абстракцию, что упрощает модификацию прототипа. 

В класс ToggleSwitch добавим переменную-объект theSemaphore, а в ме¬ 
тод инициализации этого класса — еще один оператор: 
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Рис. 8-6. Прототип интерфейса пользователя. 

theSemaphore <— Semaphore forMutualExclusion. 

Этот оператор создает и инициализирует новый объект «семафор» в 
объекте, представляющем переключатель. Поскольку мы теперь получили ак¬ 
тивный объект внутри объекта-переключателя, нам нужно быть очень вни¬ 
мательными при работе с семафором при очистке состояния переключателя. 

Определим теперь следующий метод: 


theSemaphore terminateProcess. 
trueAction <— nil. 
falseAction <— nil. 
super release 

Нам нужно изменить только один метод state:. В имеющийся код те¬ 
перь достаточно включить этот метод. Метод state: будет выглядеть так: 

state: aBoolean 

«Set the state of the toggle switch. aBoolean is expected to be of the class Boolean.» 

theSemaphore critical: 

[state - aBoolean 
ifFalse: 

[state <— aBoolean 
self changed: #state. 
state 

ifTrue: 

(trueAction value] 

ifFalse: 

[falseAction value]]] 

Теперь в критическую точку программы может вмешаться только один 
из процессов. 
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Рис. 8-7. Диаграмма объекта верхнего уровня. 

8.2. ПРОЕКТИРОВАНИЕ 
Структура объекта 

В процессе анализа предметной области и создания прототипа интер¬ 
фейса мы выделили ключевые абстракции данной области. Мы завершили 
первый этап 00D — идентификацию классов и объектов верхнего уровня. 
Теперь необходимо принять проектные решения по структуре найденных аб¬ 
стракций и их взаимоотношениям. Необходимо создать также механизмы 
связи между абстракциями, чтобы упростить процесс проектирования. Все 
это составляет логическую модель системы, которую надо представить в ви¬ 
де диаграммы классов и объектов. Выбор языка Smalltalk не требует нали¬ 
чия диаграммы модулей. 

В языке Smalltalk базовым элементом модульной декомпозиции является 
класс и для всех классов, кроме категорированных (которые являются не 
столько элементами языка, сколько оболочки Smalltalk), другого способа рас¬ 
пределения в пакеты не существует. 

Структура объекта верхнего уровня. Структура объекта верхнего уров¬ 
ня для системы домашнего отопления показана на рис. 8-7. На ней показан 
единственный объект — сама система отопления. Из диаграммы видно, что 
этот объект имеет несколько статических каналов управления. Базовым 
классом для этого объекта является HomeHeatingSystem (на рис. это прямо 
не показано). В отношении данного объекта можно предположить возмож¬ 
ность следующих манипуляций: 

* Отключение (powerDown). 

* Включение (powerUp). 

Эти две операции и образуют интерфейсный протокол класса 
HomeHeatingSystem. 

Декомпозиция на верхнем уровне. Объект верхнего уровня имеет внут¬ 
реннюю структурную иерархию: в класс HomeHeatingSystem должны войти 
такие объекты, как обогреватель, выключатель, клапаны и т.д. В данной 
структурной иерархии объекты более низких уровней должны входить в за¬ 
щищенную часть объектов более высокого уровня. Было бы ошибкой сделать 
все объекты, связанные с ключевыми абстракциями, взаимно видимыми; это 
только усложнит задачу и не будет отражать действительный уровень абст¬ 
ракций. Гораздо правильнее выбрать из списка ключевых абстракций такие, 
которые представляют самые крупные, принципиальные фрагменты системы, 
т.е. абстракции самого верхнего уровня. 

Такими фрагментами, по-видимому являются: обогреватель, регулятор, 
интерфейс оператора и дом. Именно их мы включим в качестве непосредст¬ 
венных компонент в главный объект — систему отопления. Интерфейс посе¬ 
тителей в отличие от интерфейса оператора не включен в состав верхнего 
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уровня, поскольку он в принципе связан с каждым конкретным помещени¬ 
ем. Отметим, что принятое нами решение мало отличается от диаграммы 
объектов на рис. 8-2. На рис. 8-2 объекты-помещения представлены в виде 
элементов верхнего уровня, а сейчас мы объединили их в более общую абс¬ 
тракцию — дом. Это решение основано главным образом на том, что 
имеется по меньшей мере одна общая операция для всех помещений: закры¬ 
тие всех клапанов подачи воды в случае каких-либо неисправностей в сис¬ 
теме. 

Детализация объектов верхнего уровня и их связей. Теперь приступим 
к более детальной проработке объектов верхнего уровня и связей между ни¬ 
ми. В гл. 6 рассматривался общепринятый подход к составлению диаграмм 
объектов, когда все объекты данного уровня абстракции сначала перечисля¬ 
ются, затем попарно анализируются возможные связи между ними и, нако¬ 
нец, определяется протокол связи в виде сообщений между объектами. 

Можно предположить, что обогреватель и интерфейс оператора должны 
быть видимы друг для друга. При включении обогревателя должно посы¬ 
латься сообщение оператору через индикатор состояния обогревателя. Однако 
в требованиях сказано, что перед включением индикатора должны откры¬ 
ваться клапаны подачи воды в комнатах. Это может быть сделано, если 
обогреватель может запоминать перечень комнат, нуждающихся в подаче 
тепла, либо запрашивать эту информацию у регулятора. Оба решения име¬ 
ют недостатки: приходится делать видимыми объекты совершенно различного 
уровня и структуры. Допустим другой вариант: делаем видимыми 
обгреватель и дом. Это тоже неверно, поскольку информация о потребности 
в тепле должна формироваться в комнатах независимо от активности 
обогревателя. Главная функция обогревателя состоит в генерации тепла, а 
не в распределении его по комнатам. Последний вариант состоит в наличии 
связей между домом и интерфейсом оператора. Снова непонятно, что общего 
между этими двумя объектами. 

Приходим к выводу о том, что обогреватель, интерфейс оператора и 
дом не имеют связи между собой. Все эти объекты связаны двусторонней 
связью только с регулятором, что соответствует физической структуре систе¬ 
мы, показанной на рис. 8-1. В этом нет ничего странного, поскольку про¬ 
цесс проектирования всегда должен отражать логику реальной действительно¬ 
сти. Теперь следует выявить операции, которые регулятор может выполнять 
над объектами, имеющими с ним связь. Подходя к этому вопросу с точки 
зрения интерфейса объектов, можно предложить следующий перечень: 

* Для обогревателя Включение (activate) 

Выключение (deactivate) 

* Для интерфейса оператора Неисправность (reportFault) 

Состояние обогревателя (reportFurnaceStatus) 

* Для дома Закрыть все клапаны (closeAHWaterValves) 

Закрыть один клапан (closeWaterValve) 

Открыть один клапан (openWaterValve) 

Таким образом, образован базовый интерфейс с обогревателем, операто¬ 
ром и домом. Теперь следует рассмотреть ту же проблему с другой стороны 
и выявить операции тех же трех объектов по отношению к регулятору: 
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Рис. 8-8. Диаграмма объектов системы отопления. 


* От обогревателя 


* От оператора 


* От дома 


Реакция на неисправность (respondToFumaceFault) 
Обогреватель не работает 
(respondToFumaceNotRunning) 

Обогреватель работает (respondToFumaceRunning) 
Требуется увеличить температуру воздуха 
(respondToFaultResetSwitch) 

Требуется увеличить температуру воздуха 
(respondToHeatSwitchOff) 

Выключение отопления (respondToHeatSwitchOn) 
Требуется увеличить температуру воздуха 
(needsHeat) 

Не требуется увеличить температуру воздуха 
(noLongeNeedsHeat) 


Отметим, что такой протокол строго и логично разделяет все связанные 
объекты. От обогревателя требуется только выполнять активизацию и дезак¬ 
тивизацию и сообщать о неисправности. Интерфейс оператора формирует 
только соответствующие сообщения оператору. Дом также реализует только 
самые общие абстракции. Регулятор не знает ничего о таких деталях, как 
температура в комнатах и есть ли в них кто-нибудь. Потребность в тепле 
определяется в рамках каждого помещения, где имеется для этого вся ин¬ 
формация. Регулятору известно также все, для того чтобы определить, ка¬ 
кие клапаны следует открывать. 
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Рис. 8-9. Диаграмма классов верхнего уровня. 

Почему на данном уровне абстракции не показаны непосредственно по¬ 
мещения? Дело в том, что абстракция помещения имеет две особенности. 
Во-первых, с физической точки зрения логично, что комнаты сгруппированы 
в объект-дом. Во-вторых, имеется операция закрытия сразу всех клапанов 
во всех помещениях в случае неисправностей в системе отопления. Такую 
операцию очень удобно реализовывать в одном объекте-доме в виде итерато¬ 
ра, который применяется ко всем объектам-помещениям. Поэтому на данном 
уровне абстракции определен объект-дом, через который осуществляется 
связь с помещениями. 

Все принятые проектные решения отражены на рис. 8-8. Каждый из 
объектов отмечен определением «статический»: по сути задачи нет смысла 
динамически создавать или ликвидировать основные объекты системы. Это 
типично для задач управления процессами. Основные элементы не могут по¬ 
явиться или исчезнуть в системе отопления: они существуют с момента 
включения системы до ее отключения. 

На данном этапе у нас нет оснований судить ни о видах отношений 
между объектами, ни о природе возможного параллелизма (в системе воз¬ 
можны одновременные события и может потребоваться синхронизация сооб¬ 
щений). Поэтому мы откладываем рассмотрение этих особенностей. 
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Теперь мы имеем осмысленную структуру абстракций и знаем их свя¬ 
зи. 

Определены границы каждого объекта и достигнута максимальная сте¬ 
пень разделения их структуры. Разумеется, на этом процесс проектирования 
не заканчивается: определен лишь интерфейс самых важных объектов. Оста¬ 
ется детальная проработка каждого объекта, их обобщение и выбор способа 
представления. Следует отметить, что мы уже частично установили для ряда 
основных объектов границы соответствующих им классов. Мы имеем теперь 
все необходимое для того, чтобы создать структуру классов нашей системы, 
которая является (как было показано в гл. 1) основой любой системы. Не 
следует стремиться окончательно описать интерфейс всех классов, поскольку 
этот процесс имеет характер последовательного приближения. В первую оче¬ 
редь мы должны зафиксировать самые важные проектные решения, отложив 
на время мелкие, несущественные детали, которые будут добавляться по ме¬ 
ре функционального насыщения проекта. 

Структура классов верхнего уровня. На рис. 8-9 показана структура 
классов самого верхнего уровня. Отношения использования между классами 
здесь выражены гораздо сильнее, чем отношения наследования. Система 
отопления составлена из ряда элементов, таких, как обогреватель или регу¬ 
лятор, но не является разновидностью этих элементов и не эквивалентна 
сумме составных частей. Поэтому в реализацию класса HomeHeatingSystem 
входят составными частями классы Operatorinterface, HeatFlowRegulator, 
Home и Furnace. Используется также класс ClockCalendar (часы/календарь), 
который будет рассмотрен подробнее. Отметим, что все составляющие систе¬ 
му классы «невидимы» для класса HomeHeatingSystem, поскольку сама сис¬ 
тема является более высоким уровнем абстракции по отношению к составля¬ 
ющим ее классам. На рис. 8-9 отражены также количественные характери¬ 
стики отношений: существует только по одному объекту каждого используе¬ 
мого класса. В свою очередь каждый используемый класс принадлежит толь¬ 
ко одной системе отопления. 

Из рис. 8-8 было видно, что объекты класса HeatFlowRegulator переда¬ 
ют сообщения объектам классов Operatorinterface, Home и Furnace, а те в 
свою очередь могут передавать сообщения объекту класса HeatFlowRegulator. 
Это означает наличие взаимной «видимости» классов Operatorinterface, 
HeatFlowRegulator, Home и Furnace. На рис. 8-9 это отражено в явном ви¬ 
де: двусторонние отношения использования показаны для каждой пары ука¬ 
занных классов. 

Например, функции класса Furnace имеют доступ к интерфейсу 
HeatFlowRegulator, чтобы иметь возможность передачи сообщений, входящих 
в интерфейс регулятора (таких, как respondToFurnaceFault). Это пример от¬ 
ношений использования в разделе реализации класса. Почему на рис. 8-9 
показаны отношения использования для интерфейсной части? Причина этого 
состоит в том, что объекты этих классов должны инициализироваться экзем¬ 
плярами взаимовидимых классов. В реализации класса Furnace, например, 
имеется следующий оператор: 

theHeatFIowRegulator respondToFumaceNotRunning. 

Этот оператор служит для передачи сообщения respondToFurnaceNot- 
Running объекту theHeatFIowRegulator. Из этого вытекает необходимость ис- 
15 Гради Буч 
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пользования классом Furnace интерфейса класса HeatFlowRegulator (сообще¬ 
ние должно быть «видимым»). Мы можем поставить вопрос так: каково зна¬ 
чение переменной theHeatFlowRegulator? Эта переменная является объектом 
класса Furnace и должна инициализироваться как объект регулятора. Для 
этого в классе Furnace имеется следующий метод инициализации: 

initialize: aHeatFlowRegulator 

«Initialize the furnace. aHeatFlowRegulator is expected to be of the class HeatFlowRegulator.» 


Из примера видно, что класс HeatFlowRegulator должен быть «видимым» 
как для интерфейса, так и для реализации класса Furnace. 

Поскольку интерфейс класса Furnace зависит от интерфейса класса 
HeatFlowRegulator, может показаться, что возникает циклическая завязка 
при компиляции. В языке Smalltalk такой проблемы не возникает по двум 
причинам. Во-первых, компиляция в Smalltalk реализует позднее связывание 
имен с переменными. Это означает, что из факта зависимости интерфейсов 
Furnace и HeatFlowRegulator не вытекает проблем, поскольку класс конкрет¬ 
ного параметра будет определен только в процессе выполнения кода. В 
строго типизированных языках мы уже не могли бы так легко устранить 
подобную циклическую зависимость. Почему мы так подробно останавлива¬ 
лись на этом вопросе? Потому что решение, связанное с интерфейсной час¬ 
тью, действительно соответствует сути задачи, а не связано с выбранным 
языком. 

Уточнение отношений и структуры классов верхнего уровня. На осно¬ 
ве проектных решений, отраженных на рис. 8-9, мы можем приступить к 
проработке интерфейсов для некоторых классов верхнего уровня. Для класса 
HomeHeatingSystem можно предложить следующую структуру: 


Cardinality: 

Hierarchy: 

Superclasses: 

Metaclass: 

Public Interface: 

Operations: 

Implementation: 

User: 


Fields: 


Concurrency: 


HomeHeatingSystem 


Object 

HomeHeatingSystem class 

powerDown 

powerUp 

ClockCalendar 

Furnace 

HeatFlowRegulator 

Home 

Opera torlnterface 
theFumace 
theHeatFlowRegulator 
theHome 

theOpera torlnterface 


Каждый класс в Smalltalk подразумевает наличие метакласса. В процес¬ 
се проектирования необходимо документировать только основные метаклассы, 
т.е. те, которые связаны со специфическими для задачи методами. Напри¬ 
мер, в метаклассе класса HomeHeatingSystem может быть определен метод 
инициализации объектов этого класса. Такой метакласс может иметь следу¬ 
ющую структуру: 
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Рис. 8-10. Диаграмма класса Timer. 

Name: HomeHeatingSystem class 

Cardinality; i 

Public Interface: 

Operations: create 

На рис. 8-9 показан класс ClockCalendar, хотя в перечне ключевых аб¬ 
стракций он не упоминался. По условиям требовалось наличие только тай¬ 
мера, отсчитывающего интервалы времени в 1 с. Однако упоминались и со¬ 
бытия с интервалами в минуты (например, время ожидания до перезапуска) 
и даже дни (период графика посещения комнат). Это означает, что словарь 
предметной области содержит время в секундах, минутах, часах и днях. 
Класс Timer необходим в проекте, однако есть смысл ввести более абстракт¬ 
ный класс, связанный с обобщением понятия времени. Поэтому введен класс 
ClockCalendar, который является таким же таймером, но позволяет измерять 
интервалы времени, необходимые для нашей задачи. 

На рис. 8-10 изображена структура классов для ClockCalendar и Timer. 
Заметим, что класс ClockCalendar унаследован от класса Timer и что оба 
класса имеют свои метаклассы. Метаклассы нужны для инициализации объ¬ 
ектов; например, при создании объекта часы/календарь инициализируются 
параметры неделя, час, минута и секунда, чтобы синхронизировать работу 
системы с реальным временем. Время должно быть единым для всей систе¬ 
мы, поэтому интервал в секундах регистрируется в переменной класса, что¬ 
бы все объекты класса Timer и его подклассов использовали общее показа¬ 
ние времени. Чтобы инициализировать такую переменную класса, необходи¬ 
мо иметь соответствующие методы метакласса. 

У внимательного читателя может возникнуть вопрос о необходимости 
разделения классов Timer и ClockCalendar. Это разделение сделано для того, 
чтобы расширить возможность повторного использования данных классов в 
других задачах. Класс Timer позволяет только регистрировать интервалы 
времени в 1 с. Класс ClockCalendar, напротив, связан с особенностями пред¬ 
метной области и реализует события более высокого уровня. 




Рис. 8-11. Диаграмма классов интерфейса оператора. 

Из рис. 8-10 видно, что объекты класса Timer (а следовательно, и 
класса ClockCalendar) имеют активный канал управления. В системах, свя¬ 
занных с реальным временем, как и в случае с системой отопления, состоя¬ 
ние системы изменяется в соответствии с ходом времени. Поэтому необходи¬ 
мо регистрировать временные события и лучше всего это сделать с помощью 
простейшего класса Timer. Теперь мы отложим на время рассмотрение про¬ 
цесса регистрации времени и обратим внимание на организацию процессов 
системы в целом. 

На рис. 8-11 показана принятая нами в проекте структура классов ин¬ 
терфейса оператора. На этапе создания прототипов мы определили, что этот 
интерфейс содержит выключатель отопления, переключатель-индикатор по¬ 
вторного пуска и индикатор состояния обогревателя. Следовательно, класс 
Operatorlnterface должен использовать в своей реализации классы составляю¬ 
щих его объектов. Интерфейс оператора не является простой суммой этих 
объектов, поэтому в данном случае (как и для HomeHeatingSystem) умест¬ 
нее отношения использования, а не наследования. Использование относится 
только к реализации, но не к интерфейсу, так как HeatSwitch, 
FaultResetSwitchlndicator и FurnaceStatusIndicator являются защищенными 
объектами в Operatorlnterface. 

Класс HeatSwitch унаследован от класса ToggleSwitch. Из рис. 8-11 вид¬ 
но, что класс FaultResetSwitchlndicator также унаследован из того же абст¬ 
рактного класса. Мы исходим из того, что объект переключатель-индикатор 
больше похож на переключатель, чем на обычный индикатор. 

Можно ли здесь воспользоваться множественным наследованием? В част¬ 
ности, можно ли образовать класс FaultResetSwitchlndicator из классов 
ToggleSwitch и Indicator? Ответ будет отрицательным, поскольку переключа¬ 
тель-индикатор не соответствует поведению комбинации переключателя и 
индикатора. Это простой переключатель, который может быть установлен 
пользователем только в одно из положений, а программой в другое. Это по¬ 
ведение является разновидностью поведения класса ToggleSwitch. 
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Рис. 8-12. Диаграмма классов Ноте (Дом). 

Структура класса Ноте показана на рис. 8-12. С логической точки 
зрения дом — это совокупность комнат. Следует ли из этого, что класс 
Ноте должен быть подклассом предопределенного класса Set? Ответ вновь 
отрицательный. Дом действительно состоит из помещений, но его поведение 
не является поведением обычного множества (Set), которое включает опера¬ 
ции включения, исключения, объединения и пересечения. Мы ранее уже 
упоминали, что для дома в целом определена одна главная операция 
closeAllWaterValue и две операции в отношении отдельных помещений — 
openWaterValue и closeWaterValue. Операции над множествами здесь неуме¬ 
стны. 

Можно возразить, что дом имеет черты множества и должен рассматри¬ 
ваться как подкласс от класса Set. Проектировщик всегда готов к таким 
возражениям. Конечно, использование предопределенного класса ускоряет ра¬ 
боту над проектом и такой подход часто используется для создания прото¬ 
типа. Но если мы хотим создать продукт, который затем будет использо¬ 
ваться и развиваться в течение долгого времени, то следует стремиться от¬ 
ражать суть абстракции. Это требует дополнительных затрат в процессе про¬ 
ектирования, но окупается в процессе эксплуатации продукта. 

Для класса Ноте мы установили, что в его реализации можно восполь¬ 
зоваться классом Set (для отражения перечня помещений), а в интерфейс¬ 
ной части следует использовать класс Room (помещение). Вынесение класса 
Room в интерфейс объясняется тем, что регулятор тепла должен иметь до¬ 
ступ ко всем помещениям в доме. В количественном отношении дом может 
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состоять из п помещений, но каждое из помещений принадлежит одному 
дому. Оставшаяся часть диаграммы не требует пояснений. Приведенная 
структура соответствует иерархии, показанной на рис. 8-3. Класс Room ис¬ 
пользует (включает в себя) классы DesiredTemperatureSensor, 
CurrentTemperature-Sensor, LivingPattern, WaterValue и RoomOccupancySensor. 
Количественные соотношения везде взаимооднозначны. Все комнаты связаны 
с общим регулятором тепла, который может посылать сообщения в любое 
помещение. 

На рис. 8-12 представлено несколько новых классов. При разработке 
класса для комнаты мы нашли возможность обобщения. Таким образом был 
введен абстрактный класс датчика (Temperature Sensor) как для желаемой, 
так и для текущей температуры, измеряющей величины по Фаренгейту. 
Другим еще белее общим абстрактным классом является SimpleSensor, кото¬ 
рый соответствует получаемому от внешнего устройства значению, без уточ¬ 
нения его смысла и способа получения. Для отражения особенностей измере¬ 
ния температуры по Фаренгейту (диапазон и точность) используется класс 
Temperature. Поэтому в абстрактном классе TemperatureSensor (унаследован¬ 
ном от класса SimpleSensor) введено значение класса Temperature. 

Следует обратить внимание на то, что не все принятые проектные ре¬ 
шения могут быть реализованы на языке Smalltalk. В частности, допустив, 
что температурный датчик — это простой датчик, измеряющий температуру 
по Фаренгейту, мы изменили структуру класса. Разумно предположить, что 
диапазон измерения лежит в пределах 0-300” F с дискретностью 0,1” F. По¬ 
скольку в Smalltalk используется только позднее связывание объектов с име¬ 
нами, мы не имеем средств, позволяющих непосредственно реализовать это 
проектное решение. В языках со строгой типизацией, таких, как Object 
Pascal и Ada, эти решения было бы можно реализовать на этапе компи¬ 
ляции. Другим примером затруднений, связанных с языком Smalltalk, явля¬ 
ется невозможность отражения некоторых количественных отношений. Из 
рис. 8—12 видно, что TemperatureSensor, SimpleSensor и SimpleValue явля¬ 
ются абстрактными классами. Но Smalltalk не позволяет легко ограничить 
число объектов данного класса. Нам пришлось бы использовать сомнитель¬ 
ный прием образования метода new в метаклассах, что значительно услож¬ 
нило бы задачу. Для реализации принятых проектных решений на Smalltalk 
придется пересматривать код или использовать другие средства анализа. В 
нашем случае мы можем найти способы обхода ограничений, но в больших 
проектах желательно использовать языки, непосредственно поддерживающие 
подобные проектные решения. Об ограниченных возможностях Smalltalk 
свидетельствует проблема «видимости» классов. Все классы Smalltalk глобаль¬ 
ные. Из рис. 8-12 следует, что только класс Room использует в своей реа¬ 
лизации класс LivingPattern. Это решение принципиальное, так как в боль¬ 
ших системах с огромным числом классов невозможно сконцентрировать 
внимание на отдельных деталях поведения без ограничения видимости. К 
сожалению, в Smalltalk нет механизма таких ограничений. 

Если используемый язык программирования не позволяет реализовывать 
некоторые проектные решения, то зачем мы их документируем? Смысл этой 
работы в том, чтобы лучше разобраться в логике проекта, а главное оста¬ 
вить «следы» наших рассуждений для тех, кто будет сопровождать и разви¬ 
вать проект в дальнейшем. Программа на ассемблере не позволяет быстро 
вникнуть в логику кода. Означает ли это, что мы должны оставить коммен¬ 
тарии к проекту только в его коде? Конечно нет, поэтому мы оставляем в 
документации и те решения, которые в коде не могут найти отражения. 
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Рис. 8-13. Диаграмма классов для обогревателя. 

На рис. 8-13 приведена диаграмма классов обогревателя, аналогичная 
структуре, показанной на рисунке 8-12. Мы видим, что обогреватель состоит 
из датчика температуры воды, датчика подачи топлива, датчика сбоя горе¬ 
ния, котла, клапана топлива и воспламенителя. Класс Furnace включает со¬ 
ответствующие этим объектам классы. 

Класс OilValve обобщен до уровня SimpleValve (простого клапана), кото¬ 
рый на рис. 8-12 показан в качестве суперкласса WaterValve. Клапаны для 
воды и топлива управляют подачей разных жидкостей, но и тот и другой 
могут только открываться и закрываться. 

Таким образом, основа системы создана: мы определили ключевые абст¬ 
ракции, их отношения и границы.. Теперь следует выделить главные функ¬ 
циональные фрагменты системы, описать их интерфейс и осуществлять реа¬ 
лизацию. Но прежде чем приступить к такой детальной проработке, мы 
должны установить архитектуру процессов системы, учитывая результаты 
этапа создания прототипов. 

Архитектура процессов 

В гл. 2 показано, что задачи, решаемые • системой, обычно можно раз¬ 
ложить на достаточно независимые подзадачи. До сих пор мы занимались 
разработкой структуры классов, отражающих логику ключевых абстракций. 
Теперь на основе полученного статического каркаса мы можем начать рас¬ 
смотрение потоков управления в разрабатываемой системе. 

Каналы управления. Определим, где в нашей системе находятся каналы 
управления. Один активный процесс мы уже называли в связи с таймером 
(а следовательно, и с часами/календарем). Анализируя систему, мы обнару¬ 
жим множество асинхронных событий, которые влияют на ее поведение и 
могут быть одновременными. Например, одновременно в двух комнатах мо- 
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жет быть установлено новое значение желаемой температуры, кто-то поки¬ 
дает третью комнату, а в четвертой комнате упала температура (открыто 
окно). Из этого следует, что датчики системы тоже представляют активные 
каналы управления. Большую часть времени они находятся в пассивном 
ожидании событий. Но теоретически эти события могут происходить одно¬ 
временно во всех датчиках. Попытаемся проследить за последствиями двух 
таких событий в системе и сделать так, чтобы архитектура процессов защи¬ 
щала общие данные и сохраняла возможность использования преимуществ 
параллелизма. 

Объекты класса ClockCalendar определяют интервалы времени, использу¬ 
емые другими объектами системы. Возвращаясь к исходным требованиям, 
вспоминаем, что только два класса объектов реагируют на временные собы¬ 
тия — обогреватель и недельный график. Обогреватель использует время 
для двух целей: вентилятор может останавливаться через 5 с после закры¬ 
тия клапана топлива, а повторное включение обогревателя не может выпол¬ 
няться ранее чем через 5 мин после остановки. Реализация такого поведе¬ 
ния требует регистрации соответствующих событий и лучше всего это делать 
в самом объекте-печке. Аналогично недельный график посещений должен 
учитывать ход времени и определять ожидаемое время появления в помеще¬ 
ниях людей в пределах 30 мин. Каждые полчаса отмечаются изменения в 
графике посещений. 

Возникает вопрос: как отмечать в этих объектах течение времени? Оче¬ 
видный ответ состоит в том, что часы/календарь должны посылать в эти 
объекты соответствующую информацию. Но откуда часы/календарь будут 
знать, кому в данный момент нужна информация? Следует вновь воспользо¬ 
ваться механизмом зависимостей Smalltalk. Достоинство этого механизма в 
том, что часы/календарь отделяются от классов Furnace и LivingPattern. 
Класс ClockCalendar даже не должен быть «видим» для этих двух классов, 
а это означает большие возможности повторного использования классов и 
также упрощает сам класс ClockCalendar, делая его более абстрактным. 

Данное проектное решение отражено на рис. 8-14. Обогреватель и гра¬ 
фик делаются зависимыми по отношению к объекту класса ClockCalendar 
(который является глобальным). По мере прохождения времени часы/кален¬ 
дарь посылают сообщения changer:, а затем update: каждому из зависимых 
объектов; при этом часы/календарь не обязаны «знать», сколько имеется за¬ 
висимых объектов от одного класса ClockCalendar, так как они могут управ¬ 
лять любым количеством графиков, поэтому часы/календарь не изменяются 
в зависимости от числа комнат, обслуживаемых системой. 

Отметим наличие доступа к часам/календарю от зависимых объектов 
(через итератор по всем зависимым объектам), а зависимые объекты доступ¬ 
ны для часов/календаря непосредственно. 

Объект часы/календарь должен быть доступен для таких объектов, как 
обогреватель, поскольку для них требуется отсчет времени. Доступ к ча¬ 
сам/календарю осуществляется путем включения класса ClockCalendar; лек¬ 
сически оба объекта оказываются в общей зоне «видимости». 

Так как мы хотим, чтобы время для всех связанных объектов было 
единым, мы должны образовать класс Timer и его метакласс, позволяющие 
хранить нужные значения в переменных класса, а не в переменных объек¬ 
тов. Timer в нашей задаче моделирует активный процесс, изменяющий каж¬ 
дую секунду значение единственной переменной. Для метакласса Timer 
структура может быть следующей: 
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Рис. 8-14. Диаграмма объекта часы!календарь (Clock!Calendar). 


Cardinarchy: 

Public Interface: 

Operations: 


Implementation: 


User: 

Fields: 


Concurrency: 


Timer class 


elapsedSeconds 

elapsedSeconds 

initialize 

Semaphore 

elapsedSeconds 

TheSemaphor 

TimerProcess 


Методы initialize и release для этого метакласса будут следующими: 

initialize 


«Reset elapsedSeconds, then start the process to update elapsedSeconds every second.» 
TheSemaphor <— Semaphor forMutualExclusion. 

ElapsedSeconds <— 0. 

TimerProcess <— [[Delay forScconds: I) wait. 

self elapsedSeconds: self elapsedSeconds+1 
true] whilcTrue] newProcess. 

TimerProcess resume 

«Stop the process to update elapsedSeconds every second.» 

TheSemaphor lerminateProcess. 

TimerProcess Terminate 

В методе инициализации создаются новый семафор и процесс таймера. 
Этот процесс, находясь в состоянии активизации, возбуждается каждую се¬ 
кунду и увеличивает на единицу переменную ElapsedSeconds. 
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Теперь запишем следующее определение: 

elapsedSeconds: anlnteger 

«Set the number of seconds that have elapsed since the object was Initialized, anlnteger is 
expected to be of the class Integer.» 

TheSemaphor critical: 

[ElapsedScconds <— anlnteger. 
self changed: #clapsedSeconds] 

Уже говорилось, что класс ClockCalendar является подклассом класса 
Timer, ориентированным на особенности конкретной задачи. В классе 
ClockCalendar добавляются методы пересчета секунд в минуты, часы, сутки 
и дни недели. Чтобы непосредственно наследовать от класса Timer его пове¬ 
дение, в класс Timer вводятся переменные класса DayOfWeek, Hour, Minute, 
Second. Эти переменные должны быть инициализированы в метаклассе 
ClockCalendar следующим образом: 

initializcDayOfWeck: aDay hour: anHour minute: aMinute 

..ni'Hize the clock/calendar. aDay is expected to be of the class Integer (range 1 to 7), 
anHour is expected to be of the class Integer (range 0 to 23), and aMinute is expected to be 
of the class Integer (range 0 to 59).» 

DayOfWeek <— aDay. 

Hour <— anHour. 

Minute <— aMinute. 

Seconds <— 0. 
super initialize 

В требованиях к системе говорится о двух временных событиях: 5 с 
(для выключения вентилятора) и 30 мин (для графика посещений). Задерж¬ 
ка в 5 мин для перезапуска обогревателя будет реализована иначе, посколь¬ 
ку в этом случае нужно знать время последней остановки обогревателя. 
Учитывая это, изменим содержание метода elapsedSeconds:, чтобы он отве¬ 
чал условиям двух указанных выше событий. Метод elapsedSeconds: в мета¬ 
классе ClockCalendar будет следующим: 

elapsedSeconds: anlnteger 

«Set the number of seconds that have elapsed since the object was initialized, and update the 
day of the week, hour, and minute, anlnteger is expected to be of the class Integer.» 

TheSemaphor critical: 

(ElapsedSeconds <— anlnteger. 
self changed: «elapsedSeconds. 

(Seconds rem: 5) - 0 
іГГгие: 

[self changed: #rivcSecondEvent]. 

Seconds <— Seconds + 1. 

Seconds - 60 
ifTruc: 
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[Seconds <— 0. 

(Minute rent: 30) - 0 


[self changed: #thirtyMinuteEvent]. 

Minute <— Minute + 1. 

Minute - 60 

ifTrue: 

[Minute <— 0. 

Hour <— Hour + 1. 

Hour - 24 

ifTrue: 

[Hour <— 0. 

DayOfWeek <— DayOfWeek + 1. 

DayOfWeek - 8 
ifTrue: 

[DayOfWeek <— 1]]]]] 

Поскольку мы сделали таймер активным объектом, мы должны реализо¬ 
вать класс LivingPattern (распорядок дня) в виде блокированного класса, 
чтобы избежать столкновения различных процессов (процессов таймера и 
процессов в помещении). Необходимо принять меры предосторожности, так 
как объекты этого класса имеют несколько каналов управления. Использова¬ 
ние семантики блокирования (внутренний семафор, аналогичный классу 
ToggleSwitch) удовлетворяет этим требованиям. 

Такой же параллелизм возможен и для обогревателя. Показанный под¬ 
ход к решению проблемы одновременных событий является хорошим приме¬ 
ром разработки архитектуры процессов. Чаще всего поиск вероятного парал¬ 
лелизма ведется со стороны внешних событий. Если такие (параллельные) 
события обнаруживаются, то к соответствующим объектам следует добавить 
методы их разрешения. 

Асинхронные события. Мы установили, что асинхронные события 
возможны в датчиках температуры (желаемой и фактической) и в датчиках 
присутствия людей. Следовательно, соответствующие классы должны быть 
активными. Было показано, как класс DesiredTemperatureSensor сообщает 
другим зависимым объектам о факте изменения пользователем значения же¬ 
лаемой температуры в той или другой комнате (через механизм зависимо¬ 
стей языка Smalltalk). Этот прием можно использовать для других датчиков. 
Объект-комната может регистрировать состояние всех своих датчиков, а дат¬ 
чики возвращать сообщения о наличии изменений update: в объект-комнату. 
Как и в случае с классом ClockCalendar, это сильнее связывает объекты. 
Логично предположить, что в классе Room также следует предусмотреть 
блокировку. Сам класс Room является активным, поскольку в него входят 
активные объекты; то же самое относится и. к классам Operatorlnterface и 
Furnace. Классы ToggleSwitch, BoilerTemperatureSensor, OilFaultSensor и 
CombustionFaullSensor являются активными, так как они должны реагиро¬ 
вать на асинхронные (потенциально одновременные) события. По этой при¬ 
чине активны и классы Operatorlnterface и Furnace. 

Следовательно, мы можем внести соответствующие изменения в диаг¬ 
раммы классов и объектов, отражающие архитектуру процессор в системе. 
На рис. 8-15 показана диаграмма объектов системы отопления с учетом 
свойств параллельности для основных объектов. Из этой диаграммы видно 
три потенциальных канала управления: обогреватель, интерфейс оператора и 
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комнаты. Регулятор подачи тепла не имеет собственных активных процессов, 
но требует наличия блокировки. Объект-дом должен быть последовательным, 
поскольку лишь один процесс может влиять на его состояние в каждый мо¬ 
мент времени (а состояние комнат может быть подвержено воздействию не¬ 
скольких разных процессов). Отметим, что на рис. 8-15 видно, как все со¬ 
общения в системе могут блокироваться. 

Читатель может задать вопрос об уместности анализа архитектуры про¬ 
цессов на данном этапе. В гл. 2 упоминалось о задачах, связанных с мно¬ 
жественностью каналов управления (такой задачей является и система отоп¬ 
ления). В этих системах нельзя заранее предвидеть последовательность собы¬ 
тий, т.е. мы теряем способность предсказать потоки управления. Поэтому 
очень важно спроектировать архитектуру процессов, чтобы избежать потен¬ 
циальных столкновений, вызываемых наличием нескольких каналов управле¬ 
ния. В гл. 3 и 4 было показано, что существует хорошая методология пере¬ 
хода от объектно-ориентированного проектирования к архитектуре процессов, 
которая позволяет рассматривать каждый объект как узел управления. По¬ 
скольку объекты обладают внутренним защищенным состоянием, это состоя¬ 
ние может быть сохранено в условиях множества каналов управления. 

По отношению к любому проекту мы обязаны ответить на очень важ¬ 
ный вопрос о том, как изменяется поведение системы в разных условиях. 
Частично мы это уже сделали, рассмотрев воздействие на систему внешних 
событий. Есть другой интересный вопрос: что делает система в отсутствие 
внешних событий? В этом случае все процессы либо находятся в состоянии 
ожидания, либо заблокированы, а система пассивна. Действительно, в отсут¬ 
ствие внешних событий таймер ежесекундно возбуждается, а остальное вре¬ 
мя ожидает прохождение интервала времени. С этой'точки зрения мы полу¬ 
чили стабильную систему с поведением, отражающий структуру классов и 
архитектуру процессов. С помощью диаграмм объектов мы выполнили моде¬ 
лирование отдельных динамических аспектов поведения. И теперь есть все 
необходимое, чтобы завершить полную реализацию системы. Мы создадим 
несколько исполняемых систем по мере наполнения проекта функциональны¬ 
ми свойствами, чтобы последовательно оценить принимаемые проектные ре¬ 
шения и обеспечить обратную связь с пользователями системы (с заказчи¬ 
ком). 

8.3. РЕАЛИЗАЦИЯ 
Реализация интерфейса пользователя 
Принятые проектные решения, отраженные на диаграммах классов и 
объектов (рис. 8-11 и рис. 8-15), позволяют перейти к проработке интер¬ 
фейса класса Operatorlnterface, а затем к реализации его методической час¬ 
ти. Наше представление этого класса можно отразить в следующей структу¬ 
ре: 

Cardinarchy: 

Hierarchy: 

Superclasses: 

Public Interface: 

Uses: 

Operations: 


Operatorlnterface 

1 

Object 

IleatFlowRegulator 
heatS talus 
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reportFaull 

reportFumaceStatus: 

Implementation: 

Uses: FaultResetSwitchlndicator 

FurnaceS tatuslndica tor 
IlcatSwitch 

Fields: theFaultResetSwitchlndicator 

theFurnaceStatusIndicator 
thelleatFlowRegulator 
theHeatSwitch 
theView 

Concurrency: active 

Иерархическая структура интерфейса оператора показана на рис. 8-16. 
Видно, что соответствующий объект состоит из двух переключателей (switch) 
и одного индикатора (indicator). Переключатели и индикатор являются поля¬ 
ми объекта. Интерфейс класса Operatorlnterface имеет доступ к регулятору, 
а следовательно, и для полей класса регулятор также доступен. 

Рассмотрим возможные потоки управления между этими объектами. Ре¬ 
гулятор может обращаться к интерфейсу оператора сообщением ReportFault. 
Интерфейс оператора может реагировать на это сообщение передачей сооб¬ 
щения state: переключателю-индикатору. Эти сообщения могут временно 
блокироваться в соответствии с изложенным выше подходом к параллелизму. 

Выключатель отопления также может посылать сообщение 
respondHeatSwitcOn регулятору. Реализация класса ToggleSwitch, изложенная 
выше, предусматривает два блока инициализации, выполняемые при включе- 
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нии и отключении переключателя. Соответствующие блоки должны быть 
включены и в интерфейс оператора для связи с выключателем. Аналогичный 
блок необходим и для переключателя-индикатора повторного запуска. 

Для простоты на рис. 8-16 не показаны сообщения, пересылаемые от 
интерфейса оператора составляющим его полям при инициализации. Полное 
описание инициализации выглядит следующим образом: 

initialize: anHcatFlowRegulator 

«Create the operator interface for the given heat flow regulator. aHeatFlowRegulator Is expected 
to be of the class HeatFlowRegulator.» 

IheHeatFlowRegulator <— aHeatFlowRegulator. 
theHeatSwitch <— HeatSwitch new. 
theHea IS witch 

InitializeOnAclion: 

[IheHeatFlowRegulator respondToHeatSwitchOn] 

off Action: 

[IheHeatFlowRegulator respondToHcalSwitchOfr]. 
thcFaullRcsetSwitchlndicator <— FaultRcsetSwitchlndicator new. 
iheFaultRcsctSwitchlndicator 
InitializeOnAclion: 

[IheHeatFlowRegulator respondToFaullResetlndicatorOn]. 
thcFumaceStatusIndicator <— FumaceStatusIndicator new. 
thcFumaceStatusIndicator initialize. 
theView <— RcstrictedSystemVicw 
model: nil 

label: ’Operator Interface’ 
mlninumSize: 150 <3 75. 
theView borderWidth: 1. 
theView 

addSubView: theHeatSwitch trueVicw 
in: (0 @ 0 extent: 1 / 2 @ (1 / 3)) 
borderWidth: 1. 
theView 

addSubView: theHeatSwitch falseView 
in: (1 / 2 @ 0 extent: 1 / 2 @ (1 / 3» 
borderWidth: 1. 
theView 

addSubView: theFaultRcsctSwitchfndicator trueVlew 
in: (0 @ <1 / 3) extent: 1 / 2 @ (1 / 3» 
borderWidth: 1. 
theView 

addSubView: theFaultRcsctSwitchlndicator falseView 
in: (1 / 2 @ (1 / 3) extent: I / 2 ® (1 / 3» 
borderWidth: 1. 
theView 

addSubView: thcFumaceStatusIndicator indicatorView 
in: <0 @ (2 / 3) extent: 1 @ (1 / 3)) 
borderWidth: 1. 

theView controller opcnDisplayCentered: 100 @ 125 
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Рис. 8-16. Диаграмма объектов интерфейса оператора. 

Отмстим наличие в этом методе аргумента в виде объекта класса 
HealFlowRcgulator. Этот аргумент является частью структуры состояния ин¬ 
терфейса оператора и используется при инициализации блоков, передавае¬ 
мых в выключатель и в переключатель-индикатор. В частности, при вклю¬ 
чении отопления выполняется следующий блок: 

[theHeatFlowRegulatormrespondToHeatSwilchOn] 

Остальной код служит для визуализации интерфейса оператора. Поле 
theView инициализируется объектом класса RestrictedSystemView. Этот класс 
не был показан в структуре класса Operatorlnterface и на рис. 8-11 для 
простоты, но в реализации класса он используется. Класс 
RestrictedSystemView образован из предопределенного класса 
StandardtSystemView, но не позволяет пользователю переименовывать окно 
изображения. 

К объекту theView добавлены дополнительные окна. Селекторы 
TrueView и falseView в классе ToggleSwitch необходимы для прямого доступа 
к этим двум окнам. Метод завершается активизацией контроллера изображе¬ 
ния, позволяющего отобразить окно на экране дисплея. 

Реализация класса-помещения 

Для класса Room структура может быть следующей: 

Name: Room 

Cardinarchy: n 

Hierarchy: 

Superclasses: Object 

Public Interface: 

Uses: HcatFlowRcgulator 

Operations: closeWatcrValve 

initialize: location: heatFlowRcgulator: 







Concurrency: 
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Интерфейс этого класса состоит из операторов, показанных на диаграм¬ 
ме объектов рис. 8-15 и группы операций инициализации, устранения и 
изображения. Кроме уже упоминавшихся составляющих класса Room в него 
включен ряд обособленных операций, составляющих основу поведения объек¬ 
тов этого класса. 

На диаграмме объектов (рис. 8-17) показано взаимодействие объекта-по¬ 
мещения с другими объектами. Из диаграммы видно, что помещение и ча¬ 
сы/календарь находятся в общей зоне видимости. Операции взаимоотноше¬ 
ния на рисунке не показаны. При инициализации объекта-помещения 
последний регистрирует распорядок дня по часам/календарю и больше к 
этому объекту не обращается. Некоторые объекты входят в состав объекта- 
помещения в качестве полей: датчик желаемой температуры, датчик теку¬ 
щей температуры, датчик присутствия людей, распорядок дня и клапан 
подачи воды. Все эти объекты связаны с помещением механизмом зависимо¬ 
сти языка Smalltalk. Одной из операций инициализации объекта-помещения 
и его полей является установление отношений зависимостей с датчиками и 
распорядком дня. Для данной группы объектов рассмотрим поток управления 
между комнатой и регулятором. Регулятор тепла посылает в комнату сооб¬ 
щение на открытие или закрытие клапана подачи воды. Комната в ответ на 
это возвращает сообщение value: с аргументом, который означает состояние 
клапана. Аргумент является видимым, как одно из полей класса Room. 
Каждый из этих методов может блокироваться согласно логике обработки 
параллельных событий. 

На основании каких данных помещение посылает сигналы регулятору 
на возобновление или прекращение подачи тепла? В объекте-помещении есть 
все необходимые данные для формирования таких сообщений-сигналов. Дей¬ 
ствительно, объект-помещение содержит механизм контроля состояния, уп¬ 
равляемый событиями, формируемыми в пределах объекта-помещения: датчи¬ 
ки температуры, наличие людей и распорядок дня. Из рис. 8-17 видно, что 
каждый из объектов, входящих в структуру Room, посылает сообщение 
update: с символьным параметром. Символьный параметр характеризует ка¬ 
кое-либо внешнее событие, на которое помещение должно отреагировать. 
Поскольку система пассивна, порядок прохождения событий является сущест¬ 
венным и механизм контроля состояния объекта класса Room должен упоря¬ 
дочить поведение системы. 

Исходные требования говорят о том, что каждое помещение может быть 
либо свободно, либо свободно, но ожидает посетителей, либо занято людьми. 
Клапан подачи воды в комнате может быть открыт (комната обогревается) 
или закрыт (комната не обогревается). В результате можно выделить шесть 
возможных состояний объекта-помещения: 

* Помещение свободно и не обогревается. 

* Помещение свободно и обогревается. 

* Ожидание посещения без обогревания. 

* Ожидание посещения с обогреванием. 

* Присутствие людей без обогревания. 

* Присутствие людей с обогреванием. ) 

При создании объекта-помещения необходимо установить его начальное 
состояние. При включении системы отопления помещения могут быть как 
заняты, так и свободны, а некоторые уже нуждаться в обогреве. Для ини¬ 
циализации исходного состояния помещения введен отдельный метод 
setlnitialState. 


16 Гради Буч 





Рис. 8-18. Диаграмма перехода состояния для помещения. 

На рис. 8-18 приведена даграмма перехода состояний для класса Room. 
Эта диаграмма не устанавливает определенного исходного и конечного состо¬ 
яния, поскольку исходное состояние определяется динамически, а функцио¬ 
нирование системы не прекращается до ее полного отключения. 

Преобразование такой диаграммы переходов в код Smalltalk не 
представляет особых трудностей. В качестве сигналов для класса Room мож¬ 
но использовать метод update:, который реализуется через механизм зависи¬ 
мостей для всех объектов, входящих в состав помещения. Одной из возмож¬ 
ностей реализации метода update: является использование составного опера¬ 
тора if, который в зависимости от состояния объекта выбирает соответствую¬ 
щие методы реакции. Реакцией на какое-либо событие являются изменение 
состояния и формирование сообщений с помощью упоминавшихся выше 
отдельных методов. Теперь мы можем реализовать рассматриваемый метод: 

update: aMcssagc 

«Update the state of the room. Possible states are #occupiedAndt Icaling, #occupicdAndNoHeating, 
#expcctAndlIcating, #expectAndNoIIcating, #unoccupicdAndHeating, #unoccupiedAndNoHeating. 
Possible events are #occupied, #unoccupicd, #currenlTcmpcrature, #desiredTcmperature, 
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ifFalse: 


[current <— thcCurrentTemperatureSensor value. 

desired <— IheDesiredTemperatureSensor value, 
occupied <— theRoomOccupiedScnsor value, 
expected <— theLivingPattern occupancyExpected. 
currentState - #occupiedAndHeating ifTrue: 

[seU 

occupiedAndHeating: aMessage 
current: current 
desired: desired 
occupied: occupied 
expected: expected] ifFalse: 

[currentState - #occupiedAndNoHeating ifTrue: 

[self 


occupiedAndNoHeating: aMessage 
current: current 
desired: desired 
occupied: occupied 
expected: expected] ifFalse: 
[currentState - #expectAndHeating ifTrue: 

[self 


expectAndHeating: aMessage 
current: current 
desired: desired 
occupied: occupied 
expected: expected] ifFalse: 
[currentState - #expectAndNoHeating ifTrue: 
[self 


expectAndNoHeating: aMessage 


desired: desired 
occupied: occupied 
expected: expected) ifFalse: 
currentState - #unoccupiedAndHeating ifTrue: 

[self 

unoccupiedAndHeating: aMessage 
current: current 
desired: desired 
occupied: occupied 
expected: expected] ifFalse: 
[currentState - #unoccupiedAndNoHealing ifTrue: 

[self 

unoccupiedAndNolfcaling: aMessage 
current: current 
desired: desired 
occupied: occupied 
expected: expected]]]]]]]] 


В качестве альтернативной реализации можно воспользоваться опера¬ 
цией perform для выбора действий в зависимости от текущего состояния. 
Недостатком такого подхода является необходимость распаковки массива ар¬ 
гументов, используемого операцией perform. В каждом отдельном методе ре¬ 
ализуется аналогичный селектор по символу, означающему событие, текущее 
состояние, желаемую температуру, наличие людей, ожидание людей. Исходя 
из этих аргументов, можно реализовать отдельные методы, реализующие пе¬ 
реходы согласно диаграмме на рис. 8-18. Для примера рассмотрим метод 
occupiedAndNoHeating:. Изменение состояния occupiedAndNotHeating может 
быть вызвано тремя событиями (рис. 8-18): 
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* Помещение освободилось. 

* Изменилась желаемая температура. 

* Изменилась фактическая температура. 

В первом случае осуществляется переход в состояние 
expectAndNoHeating или unoccupiedAndNotHeating (в зависимости от состоя¬ 
ния ожидания, фиксируемого распорядком дня). В двух других случаях (ес¬ 
ли фактическая температура стала ниже желаемой более чем на два граду¬ 
са) потребуется подача тепла. Зафиксируем эту логику в следующем обособ¬ 
ленном методе: 

occupiedAndNoHeating: aMcssagc 
current current 
desired: desired 
occupied: occupied 
expected: expected 

«Respond to a slate change, desired and occupied are expected to be of the class Temperature, 
occupied and expected are expected to be of the class Boolean.» 

aMessage - #unoccupied 

[expected 

ifTrue: 

[currentState <— #expectAndNoIIeating] 

ifFalse: 

[currentState <— #unoccupiedAndNoHeating]]. 
aMessage - #currentTemperature I (aMessage c #desircdTemperature) 

[current <- (desired — 2) 
ifTrue: 

[currentState <— #occupiedAndHealing. 
self startHeating]] 

Если произошел переход к состоянию #occupiedAndHeating, то формиру¬ 
ется сообщение, запрашивающее подачу тепла. Соответствующий этому ме¬ 
тод StartHeating может быть следующим: 

startHeating 

«Requeest heat for this room.» 
theHealFlowRegulator necdslleat: self 

Метод startHeating будет активизироваться во всех случаях, когда про¬ 
изойдет переход из необогреваемого состояния в обогреваемое. В обратном 
случае активизируется метод stopHeating (прекращение обогрева). 

Реализация класса-обогревателя (furnace) 

Класс Furnace реализуется по схеме, аналогичной классу Room, в части 
использования механизма управления состоянием через логику зависимостей 
языка Smalltalk. Структура класса-обогревателя имеет следующий вид: 

Furnace 


Cardinality: 



Рис. 8-19. Диаграмма объектов обогревателя. 

Hierarchy: 

Superclasses: Object 

Public Interface: 

Uses: HeatFlowRegulator 

Operations: activate 

deactivate 
initialize: 

Implementation: 

Uses: BoilerTemperatureSensor 

ClockCalendar 
CombustionFaullSensor 

OilValve 

Ignitor 

OilFaultSensor 

Fields: currentState 

itsScmaphore 

thcBoilerTempcratureSensor 
thcCombustionFaultSensor 
IheHeatFlowRegulator 
theBlower 
theOilValve 
thelgnitor 
theOilFaultSensor 
theView 
timeDelay 
Operations: postFault 

postNotRunning 

postRunning 


Concurrencv: 
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Рис. 8-20. Диаграмма состояний обогревателя. 

Приведенная структура соответствует операциям, приведенным на диаг¬ 
рамме объектов (рис. 8-15). Число методов здесь невелико, поскольку меха¬ 
низм контроля обогревателя достаточно прост. 

Диаграмма объектов обогревателя показана на рис. 8-19. Так же как и 
в классе Room, здесь имеется несколько раздельных полей. Каждый из объ¬ 
ектов имеет доступ к обьекту-печке через механизм зависимостей Smalltalk. 

Поток управления в данном объекте аналогичен потоку в объекте-поме¬ 
щении. Все датчики, вентилятор и часы/календарь могут посылать сообще¬ 
ния update: с аргументами, обозначающими природу возникающих событий. 
Прохождение сообщений может блокироваться в случае их параллельности. 

Процесс включения и выключения обогревателя подробно изложен в ис¬ 
ходных требованиях. Эти процессы составляют основу поведения 
обогревателя. На рис. 8-20 показана схема состояний и переходов, соответ¬ 
ствующая указанным требованиям. Из исходного (выключенного) состояния с 
помощью метода activate осуществляется событие #activate, которое переводит 
печку в состояние awaiteActivation или awaitingBlowerStart. Конкретный вы¬ 
бор зависит от того, сколько времени прошло после последней остановки 
обогревателя. Если обогреватель находился в неактивном состоянии более 5 
мин, выбирается состояние awaitingBlowerStart. В противном случае выполня¬ 
ется переход в состояние awaiteActivation, в котором каждые 5 с проверяется 
длительность интервала времени после выключения обогревателя. 

Переход в состояние awaitingBlowerStart вызывает включение вентилято¬ 
ра, после чего возникает состояние ожидания сигнала от вентилятора (еще 
один активный канал управления) о достижении нужной скорости вращения. 
Здесь мы обнаруживаем неясность исходных требований: состояние ожидания 
сигнала от вентилятора может длиться неопределенно долго, если требуемая 
скорость вращения не будет достигнута. 
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Рис. 8-21. Диаграмма объектов регулятора подачи тепла. 

Как только принимается сигнал от вентилятора, открывается клапан 
топлива и осуществляется воспламенение. После этого вновь возникает со¬ 
стояние ожидания одного из следующих событий: 1) обнаруживается неисп¬ 
равность (переход обогревателя в состояние awaitingBlowerFault) ; 2) 

обогреватель выключается (переход в состояние awaitingBlowerStop) ; 3) тем¬ 
пература воды достигает требуемого значения (обогреватель переходит в со¬ 
стояние activated). 

Обычный порядок выключения обогревателя состоит в переходах от со¬ 
стояния activated к awaitingBlowerFault и к deactivated. После выключения 
регистрируется время остановки. Значение этого времени сохраняется в поле 
timeDelay и служит при повторном включении для проверки условия мини¬ 
мальной паузы в 5 мин. 

Реализация регулятора подачи тепла 

Нам осталось реализовать только абстракцию регулятора подачи тепла. 
Регулятор является ядром системы, поскольку именно он управляет работой 
обогревателя (включением и выключением) и регулирует подачу нагретой 
воды в помещения. Тщательная проработка структуры системы и разделение 
ее на несколько независимых объектов позволяет достаточно удобно реализо¬ 
вать класс регулятора. 

На основе уже сделанных проектных решений получим следующую 
структуру класса heatFlowRegulator: 


Cardinarchy: 


HeatFlowRegulator 
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Object 
Furnace 

Operatorlnterface 

initialize: furnace: operator: 
heedsHeat: 
noLongeNeedsHeat: 
release 

respondToFaultResetS witch 
respondToFurnaceFault 
respondToFumaceNotRunning 
respondToFurnaceRunning 
respondToHeatSwitchOff 
respondToHeatSwitchOn 

Для реализации механизма блокировки в этом классе необходим 
экземпляр переменной в виде семафора. Регулятор имеет также механизм 
управления переходом состояний, и, следовательно, должно быть поле для 
хранения текущего состояния. Для передачи сообщений от регулятора дру¬ 
гим объектам необходимо иметь также поля-ссылки на дом, обогреватель и 
интерфейс оператора. 

Требования к системе устанавливают необходимость хранения данных о 
потребностях помещений в тепле даже при пассивном состоянии 
обогревателя. Это оправдано, поскольку при активизации обогревателя нуж¬ 
но подать тепло во все помещения, которые направляли соответствующие 
сообщения. Регулятор должен обеспечивать теплом' все помещения, которые 
этого требуют. ѵ 

Перечень помещений, нуждающихся в тепле, динамически изменяется; 
он пополняется при получении сообщений needHeat и сокращается после от¬ 
крытия соответствующих клапанов подачи воды (с началом процесса нагре¬ 
вания в помещениях). Если потребуется по какой-либо причине выключить 
обогреватель (например, во всех помещениях достигнута требуемая темпера¬ 
тура), информация о перечне обогреваемых помещений сохраняется. Для 
этого введено поле, учитывающее открытые клапаны. 

Диаграмма объектов регулятора показана на рис. 8-21. Диаграмма 
аналогична диаграмме объектов верхнего уровня (рис. 8-15), но имеет боль¬ 
ше подробностей, так как регулятор является ядром управления системой. 
Однако на рис. 8-21 указан еще один объект roomsNeedingHeat, который 
появляется благодаря принятому подходу к реализации данного класса. 

Теперь мы имеем все необходимое, чтобы определить отношения «види¬ 
мости» между объектами, приведенными на рис. 8-21. В качестве полей ре¬ 
гулятора видимыми являются дом, обогреватель и интерфейс оператора. Со¬ 
ответственно видимым является и регулятор для этих объектов. 

Сообщения, которые регулятор может посылать объекту обозначенному 
roomNeedingHeat, являются сигналами на включение и исключение помеще¬ 
ний из списка, а также определение числа помещений в списке (требующих 
обогрева) через селектор size. Для реализации класса roomNeedingHeat 
можно использовать предопределенный класс Set. Для перечня помещений 
достаточно последовательной семантики. Поскольку сам регулятор имеет ме¬ 
ханизм блокировки, то для объекта roomNeedingHeat не возникает может 
иметься несколько каналов управления. 


Public Interface: 
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Рис. 8-22. Диаграмма переходов состояний для регулятора подачи тепла. 

Управление переходом состояний в регуляторе тепла сосредоточено в 
методе update:. В этом нет ничего загадочного: поскольку где-то механизм 
переходов должен быть реализован, вполне естественно поместить соответст¬ 
вующий код в том же методе, в котором его реализуют другие классы 
(обогреватель и помещение). Методы реализации переходов состояния под 
влиянием внешних событий основаны на использовании алгоритмической де¬ 
композиции. Для примера приведем реализацию метода activating: в следую¬ 
щей форме: 

activating: aMcssage room: aRoom 

«Respond to a message while in the activating state. Possible events are #needslleat, 

#noLongerNeedsHeat, #HeatSwitchOff, #fumaceFault, and #running.» 

aMessage - #needsHeat 

[(roomsNeedingHeat includes: aRoom) 
ifFalse: 

[roomsNeedingHeat add: aRoom], 

Л пі1]. 

aMessage - #noLongerNeedsHeat 
ifTruc: 





Рис. 8-23. Моделирование системы отопления. 


[roomsNeedingHeat remove: aRoom if Absent: [ ]. 
roomsNeedingHeat size - 0 
ifTrue: 

[currentState <— #dcactivatingNormal. 
[theFurnace deactivate] fork). 

л піі]. 

aMcssage - #heatSwitchOff 
ilTrue: 

[currentState <— #deactivating\ormal. 

[theFurnace deactivate] Гогк. 

л піі] . 

aMcssage - #furnaceFault 
ifTrue: 

[currentState <— #deactivatingFault. 

[theFurnace deactivate] fork. 

-nil], 

aMcssage - #running 
ifTrue: 


[currentState 
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roomsNeedingHeat do: [:x I 

x openWaterValve. 

totalValveOpen <— (total ValveOpen +1)]. 
roomsNeedingHeat <— Set new. 

[theOperatorlnterface reportFumaceStatus: true] fork. 
л пі1]. 

Полная диаграмма переходов для класса HeatFlowRegulator приведена на 
рис. 8-22. Обратим внимание на то, как на этой диаграмме отражен метод 
activating. В состоянии activating (см. диаграмму и код программы) регулятор 
может получать сообщения о событиях #needsHeat и #noLongerNeedsHeat. В 
этих случаях происходит добавление или исключение помещений из переч¬ 
ня. Если перечень становится пустым, то выполняется переход в состояние 
ожидания сигнала о запуске обогревателя (событие #running) с последую¬ 
щим переходом в состояние running. 

В состояние activating может поступить также сообщение о событии 
#heatSwitchOff (выключение температуры), которое требует отключить 
обогреватель и перейти в состояние deactivatingNormal. В случае неисправно¬ 
сти обогревателя (событие #furnaceFault) также выполняется его выключение 
с переходом в состояние deactivatingFault. Методы класса-регулятора 
обладают одной характерной чертой. Метод activating: room: может посылать 
сообщение deactivate объекту-обогревателю. Это сообщение пересылается не 
прямо, а через объект-регулятор, что является хорошим примером использо¬ 
вания посредника, т.е. объекта, выполняющего операции по сигналу другого 
объекта. Это сделано потому, что нельзя допустить блокировку регулятора 
во время отключения обогревателя. В это время могут обрабатываться сигна¬ 
лы о событиях #needHeat или #noLongeNeedHeat и блокировка регулятора 
приведет к блокировке указанных сообщений от помещений. 

Если попытаться реализовать процесс без посредника, может возникнуть 
тупиковая ситуация. Регулятор направляет сообщение deactivate объекту- 
обогревателю и блокируется до получения ответа о выключении. Получив от 
обогревателя сообщение RespondToFurnaceNotRunning, регулятор разблокиру¬ 
ется. Такая цепь зависимостей может создать тупиковые петли: обогреватель 
ожидает сигнал регулятора, а регулятор ожидает сигнал от обогревателя. 
Включение в эту цепь объектов-посредников разрывает такие виды тупико¬ 
вых петель. Почему нельзя изменить метод deactivate так, чтобы при блоки¬ 
ровке регулятора обогреватель не мог бы послать сообщение 
FurnaceNotRunning? Если заблокирован регулятор, то блокируются и запросы 
от помещений на подачу и прекращение подачи тепла. В разветвленном 
процессе разрываются тупиковые петли и повышается степень параллелизма. 

Почему мы обратились к вопросу о замкнутых петлях? Из рис. 8-21 
очевидно наличие циклических зависимостей между параллельными объекта¬ 
ми. Пути передачи сообщений между регулятором и печкой являются дву¬ 
направленными. В подобном случае проектировщик должен задать вопрос: 
могут ли сообщения направляться по обоим направлениям одновременно? 
Если ответ утвердительный, существует потенциальная опасность «гонок» 
или, что еще хуже, замкнутых петель (тупиков). 
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8.4. МОДИФИКАЦИЯ 
От моделирования к реализации 

Мы заканчиваем проектирование домашней системы отопления. В про¬ 
цессе проектирования мы получим пакет диаграмм классов, диаграмм объек¬ 
тов, описаний структур', диаграмм переходов состояний и временных диаг¬ 
рамм. На рис. 8-23 показан снимок с экрана при моделировании на языке 
Smalltalk нашей системы в полном объеме (включающем 29 специальных 
классов и примерно 100 методов). Снимок очень похож на прототип интер¬ 
фейса пользователя. Мы создали систему методом приближения на основе 
прототипа, а не путем последовательного выполнения этапов анализа, проек¬ 
тирования и реализации. Теперь проект отвечает заданным условиям и ос¬ 
тается создать систему с реальными элементами (датчики, обогреватели, пе¬ 
реключатели и т.д.). При этом интерфейсную часть классов изменять не по¬ 
требуется, нужно лишь модифицировать реализацию ряда методов, относя¬ 
щихся к внешнему окаймлению системы. 

Посмотрим, как нужно, модифицировать класс датчика Desired- 
TemperatureSensor, чтобы он отвечал требованиям реального устройства. 
Предположим, что реальное оборудование реализует обработку прерываний, 
и изменим метод value: так, чтобы он вызывался по прерыванию в момент 
изменения пользователем задаваемой температуры. Если система прерываний 
не реализуется, необходимо организовать постоянный опрос датчика и затем 
передавать значение value:. В обоих случаях интерфейс датчика сохраняется. 
Следовательно, объекты, связанные с этим датчиком, не подвержены влия¬ 
нию вносимых модификаций. 

То же самое относится и к исполнительным элементам, таким, как 
клапаны подачи воды. Модификация класса WaterValve под реальный клапан 
сводится к изменению реализации метода value:, чтобы сформировать элект¬ 
рический сигнал управления клапаном. В этом случае интерфейс и логика 
поведения класса остаются прежними, не затрагивая других проектных ре¬ 
шений. 

Корректировка исходных требований 

В процессе работы мы создали переносной проект (код обычно не пере¬ 
носится). Что произойдет, если мы теперь внесем существенные изменения в 
исходные требования? Признаком хорошего проекта является его гибкость в 
отношении подобных изменений. 

Предположим, например, что какому-либо заказчику захотелось устано¬ 
вить в данной системе отопления иное значение температуры для незанятых 
людьми помещений, причем для каждого помещения свое значение. В ис¬ 
ходных требованиях это значение является для всех комнат. Что нужно 
изменить в нашем проекте? 

Придется изменить только реализацию класса Room (помещение). Мы 
введем новый класс SetBack, моделирующий устройство задания требуемой 
температуры в отсутствие людей. В результате это значение будет принад¬ 
лежать структуре каждого помещения. Механизм управления переходами со¬ 
стояний должен учесть возможность изменения этого параметра. И наконец, 
алгоритм формирования запросов на подачу тепла в помещение должен бу¬ 
дет вместо имевшейся ранее константы использовать значение этого вновь 
введенного параметра. При этом интерфейс класса Room не изменяется: сиг¬ 
налы регулятору формируются по прежнему протоколу. В результате преж- 
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ние абстракции и механизмы нашего проекта сохранились, лишь добавлено 
новое свойство в одном фрагменте системы. 

Теперь рассмотрим возможность более серьезного изменения требований. 
Одному из заказчиков в системе отопления необходимо иметь два 
обогревателя для обслуживания большого здания. Какие изменения следует 
внести в наш проект? 

Изменения будут незначительными. Естественно, потребуется ввести еще 
один объект класса-обогревателя. Как управлять этим объектом? Регулятор 
уже имеет все необходимое для такого управления. Например, при превы¬ 
шении числа помещений, имеющих потребность в обогреве, некоторого поро¬ 
га (соответствующего возможностям одного обогревателя) регулятор включает 
второй обогреватель. Выключение также происходит в связи с уменьшением 
числа обогреваемых в данный момент помещений. И в этом случае интер¬ 
фейсная часть всех классов сохраняется, что характеризует наш проект как 
чрезвычайно стабильный. 

Дополнительная литература 

Вопросы синхронизации, тупиков, зависаний и гонок подробно рассмат¬ 
риваются Hansen [Н, 1977], Ben-Ari [Н, 1982] и Holt [Н, 1978]. 
Mellichamp [Н, 1983], Glass [Н, 1983] и Foster [Н, 1981] рассмотрели ос¬ 
новные вопросы по системам реального времени. Lorin [Н, 1972] изложил 
проблемы параллельности, связанные с взаимодействием оборудование — 
программа. 

Роль параллелизма в объектном подходе рассматривается в работах, 
приведенных в гл. 2. Обзор языка Smalltalk с примерами можно найти в 
приложении. 
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Object Pascal. Инструментальное 
средство разработки конструкций 
геометрической оптики 

В то время как Smalltalk является «чистым» языком, в котором все 
представляется в виде объектов, Object Pascal меньше всего можно считать 
объектно-ориентированным языком программирования разве что в том смыс¬ 
ле, что он добавляет к Pascal только наиболее общую поддержку классов, 
единственное наследование, динамическую связь и полиморфизм. В отличие 
от Smalltalk Object Pascal строго типирован. 

В данной главе мы используем Object Pascal для решения научных 
проблем в геометрической оптике, разделе физики, связанном с явлениями 
отражения и преломления света. При исследовании проблемы были затрону¬ 
ты вопросы синхронизации процесса и разумного распределения поведения 
между несколькими автономными, относительно статичными объектами. В 
рассматриваемой ниже проблеме преобладает два очень разных аспекта: с 
одной стороны, желание иметь дружественный и восприимчивый интерфейс 
пользователя и, с другой стороны, необходимость интенсивной обработки, ис¬ 
пользующей динамические объекты. 

9.1. АНАЛИЗ 
Ограничения 

Ниже мы сформулировали подробные требования к инструментальному 
средству разработки конструкций геометрической оптики. Мы говорили о 
таких действительных объектах, как линзы и оптические скамьи, а также о 
таких объектах, как изображения (реальные и мнимые), которые, не будучи 
явно действительными, на самом деле существуют в нашем представлении 
как абстракции с точно определенными границами. Что можно сказать в 
связи с этим о лучах света? Если исходить из волновой теории света, мы 
могли бы привести доводы о том, что свет не является объектом. Однако с 
точки зрения геометрической оптики трактование света как объекта (как 
векторов частиц) является определенным взглядом на мир, потому что он 
эффективен при моделировании явления рефракции. 

Является ли точка фокуса объектом? Точка фокуса определяется как 
некоторая точка в пространстве на фиксированном расстоянии от центра 
тонкой линзы. В ходе анализа обнаруживается, что точка фокуса не являет¬ 
ся хорошим кандидатом в объекты: нет имеющих большое значение опера¬ 
ций, связанных с точками фокуса. Лучше моделировать фокусное расстояние 
как свойство линзы, а точку фокуса как следствие этого свойства. Это ана¬ 
логично проблеме моделирования физических объектов, таких, как бейсболь¬ 
ные мячи и машины, цвета и формы которых не являются независимыми 
объектами, но существуют как свойства объектов. 
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Требования, лредъявляемые к инструментальному средству 
разработки конструкций геометрической оптики 

Основная функция данного инструментального программного средст¬ 
ва — вычисление пути луча для различных типов тонких линз, располо¬ 
женных вдоль оптической скамьи. Пользователь может манипулировать 
такими параметрами, как фокусное расстояние и расположение линз, и 
сразу же получать в виде обратной связи пути всех главных лучей, раз¬ 
мер, позицию и ориентацию результирующих изображений. 

Тонкая линза — это линза, толщиной которой можно пренеб¬ 
речь [1 ]. Нас интересуют два вида тонких линз: собирающие линзы, ко¬ 
торые в центре толще, чем по краям, и рассеивающие линзы, которые 
по краям толще, чем в центре. В собирающей линзе с реальным объек¬ 
том, помещенным в бесконечности с одной стороны, параллельные лучи, 
идущие от объекта, приблизятся к линзе, а затем сфокусируются в точке 
на другой стороне линзы. Эта точка является второй точкой фокуса лин¬ 
зы, которую мы обозначим Г. 

Если реальный объект расположен на одной стороне собирающей 
линзы в первой точке фокуса, которую мы пометим Г, параллельные лу¬ 
чи света появятся с другой стороны линзы. В тонкой линзе величины f и 
Г равны, и мы называем эту величину фокусным расстоянием линзы. 

Если реальный объект не находится ни в бесконечности, ни в точке 
фокуса, линза сформирует изображение. Пусть d — расстояние от реаль¬ 
ного объекта до центра линзы, ad’ — расстояние от центра линзы до 
изображения, тогда мы сможем записать следующее равенство: 

1/d + 1/d’ = 1/f. 

Увеличение ш точной линзы определяется по формуле: 

m = — d’/d. 

Фокусное расстояние собирающей линзы положительно, фокусное 
расстояние рассеивающей линзы отрицательно. Итак, если дана рассеива¬ 
ющая линза с помещенным в бесконечности с одной стороны линзы ре¬ 
альным объектом, параллельные лучи света от объекта приблизятся к 
линзе и рассеются. Если мы проследим путь этих рассеянных лучей в 
обратную сторону, то увидим, что они сфокусируются во второй точке 
фокуса, которая расположена с той же стороны линзы, что и реальный 
объект. 

Инструментальное средство разработки конструкций геометрической 
оптики должно быть пригодным для моделирования как собирающих, так 
и рассеивающих линз. Известны три основных типа собирающих линз: 

* собирающий мениск, 

* плоско-выпуклые линзы, 

* двояковыпуклые линзы. 

Существуют также три основных типа рассеивающих линз: 

* рассеивающий мениск, 

* плоско-вогнутые линзы, 

* двояковогнутые линзы. 

Если мы имеем реальный объект и одиночную линзу, то данное инс¬ 
трументальное программное средство должно определить размер, место 
расположения и ориентацию формируемого изображения, которое может 
быть реальным или мнимым. Например, если реальный объект, располо- | 
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жен точно позади фокусного расстояния собирающей линзы, реальное 
изображение объекта будет сформировано с другой стороны линзы. В ана¬ 
логичном случае рассеивающая линза не сформирует реальное изображе¬ 
ние, так как лучи расходятся. Тем не менее изображение объекта поя¬ 
вится с той же стороны линзы, с которой расположен реальный объект; 
мы называем его мнимым изображением. Когда вычисляется путь луча, 
инструментальное программное средство должно различать реальное и 
мнимое изображения. Понятие о формировании изображения объекта 
можно использовать и для набора линз. Мы предполагаем, что все линзы 
расположены так, что их центры находятся вдоль линии, называемой оп¬ 
тической осью. Таким образом, изображение, сформированное одной лин¬ 
зой, служит объектом для следующей линзы в ряду линз вдоль оптиче¬ 
ской оси и так далее. 

Точка, в которой формируется реальное или мнимое изображение, 
определяется пересечением только трех лучей, которые называются основ¬ 
ными лучами и описываются следующим образом: 



Рис. 9-1. Оптический эксперимент. 

1. Луч, параллельный оси, после преломления в линзе, проходит через 
вторую точку фокуса собирающей линзы или является продолжением 
луча, выходящего из второй точки фокуса рассеивающей линзы. 

2. Луч, проходящий через центр тонкой линзы, не отклоняется, так как 
две поверхности линзы, через которые проходит центральный луч, 
практически параллельны друг другу. 

3. Луч, проходящий первую точку фокуса (или идущий по направлению 
к ней), выходит параллельным оптической оси [2]. 

Рис. 9-1 иллюстрирует эти понятия. Здесь мы видим оптическую 
скамью с линейной шкалой, значения которой даны в произвольных еди¬ 
ницах. На самом левом краю находится реальный объект, за которым 
расположены три линзы на расстоянии 50, 215 и 400 единиц от реально¬ 
го объекта соответственно. Первая и вторая линзы являются собирающи¬ 
ми линзами (их фокусные расстояния имеют значения 30 и 50), а 
третья линза является рассеивающей линзой (с фокусным расстоянием — 
150). Реальное изображение показано темно-серым цветом, а мнимое изо¬ 
бражение — светло-серым цветом. 

Реальные линзы теряют качество от хроматических и монохромати¬ 
ческих аберраций, таких, как сферическая аберрация, при которой основ¬ 
ные лучи не сходятся в точку. В данном инструментальном программном 
средстве нет необходимости моделировать такое явление. Интерфейс поль¬ 
зователя инструментального средства разработки конструкций геометриче¬ 
ской оптики должен следовать стандарту интерфейса пользователя реали¬ 
зованного на PC Macintosh фирмы Apple [3]. Каждый оптический экспе- 
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римент должен быть изображен в его собственном окне, которое можно 
изменять в размерах и передвигать по экрану. Так как конкретный экс¬ 
перимент может включать много линз, то каждое окно должно быть 
предназначено для отображения произвольной, определяемой пользовате¬ 
лем части оптического эксперимента. Пользователь должен иметь возмож¬ 
ность переключать изображение оптической скамьи, линий шкалы (для 
регулирования точности расположения линз) и страницы прерываний, пе¬ 
ремещения мыши на сетке из пяти интервалов, выбрать любую из шести 
различных тонких линз из набора. Выбранную линзу можно быть поме¬ 
стить с помощью мыши вдоль оптической скамьи. Необходимо обеспечить 
интерфейс, который позволял бы пользователю устанавливать фокусное 
расстояние выбранной линзы. Пользователь должен иметь возможность 
выбрать, переместить, вырезать, скопировать, очистить и вставить как от¬ 
дельную линзу, так и набор линз. После любых действий пользователя, 
которые приводят к изменению размера, расположения и ориентации изо¬ 
бражения, инструментальное программное средство должно показать путь 
луча. Реальный объект (единственный и изображенный в позиции О 
вдоль оптической скамьи) должен быть показан черным цветом. Реальные 
изображения должны быть показаны темно-серым цветом, а мнимые изо¬ 
бражения — светло-серым цветом. 

Пользователь должен иметь возможность отображать на дисплее до 
четырех экспериментов за один раз. При этом применяются обычные 
операции над файлами: пользователь создает новые эксперименты, откры¬ 
вает старые эксперименты, сохраняет эксперименты, сохраняет копии экс¬ 
периментов, возвращается к сохраненным экспериментам. Пользователь 
должен также иметь возможность распечатать эксперимент. Функции от¬ 
мены и переделки должны быть реализованы во всех операциях пользо¬ 
вателя, которые изменяют расположение, размер и ориентацию изображе¬ 
ния. 


Сам по себе оптический эксперимент также является объектом, потому 
что этот термин обозначает нечто с точно определенными границами. Опти¬ 
ческий эксперимент включает набор линз, оптическую скамью, набор изо¬ 
бражений (как реальных, так и мнимых) и набор лучей. 

Некоторые требования, изложенные выше, повторяют математические 
постулаты геометрической оптики; остальные требования относятся к семан¬ 
тике интерфейса пользователя, которые описывают, каким образом можно 
использовать инструментальное программное средство для управления опти¬ 
ческим экспериментом. Несколько требований описывают видимые для поль¬ 
зователя процессы, такие, как удаление, чистка, копирование, вставка, пере¬ 
мещение и выбор. Вместо того чтобы представлять их в виде алгоритмиче¬ 
ских абстракций, мы можем ввести объекты, которые выступают в качестве 
посредников, ответственных за осуществление процессов. Итак, вместо того 
чтобы иметь процесс удаления, мы будем иметь объект-команду «вырезать», 
которая содержит информацию, как удалить линзы из оптической скамьи. 
Инкапсулирование такого поведения в объекте обеспечивает сложное взаимо¬ 
действие с пользователем. Например, с помощью объекта-команды «уда¬ 
лить» — легче всего узнать, как отменить операцию удаления и спасти 
удаленную линзу, чтобы ее можно было вставить обратно в это приложение 
или в другие. 

17 Гради Буч 
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Наша задача состоит в том, что мы должны построить инструменталь¬ 
ное программное средство, с помощью которого пользователь сможет беспре¬ 
пятственно манипулировать оптическими экспериментами. Нам не хотелось 
бы построить враждебный пользователю интерфейс, который заставлял бы 
его ставить оптические эксперименты и модифицировать их по этапам в по¬ 
рядке, жестко определенном инструментальным программным средством, а не 
самим пользователем (что характерно для модальных, пакетно-ориентирован¬ 
ных приложений). Вместо этого наши требования подводят нас к созданию 
редактора типа «что вы видите, то и получаете» (what you see is what you 
get (WYSIWYG)) для оптических экспериментов, который делает явно види¬ 
мыми ключевые абстракции, существующие в сознании пользователя, — 
линзы, изображения, лучи и оптические скамьи. Таким образом, после не¬ 
большой практики использования инструментального средства разработки 
конструкций геометрической оптики пользователь сможет манипулировать 
абстракциями линз так же, как если бы они были реальными объектами. 
Основное преимущество такого инструментального программного средства за¬ 
ключается в том, что во многих отношениях оно является более гибким, 
чем манипулирование реальными линзами. Например, наши требования по¬ 
зволяют пользователю легко изменить фокусное расстояние, что в реальной 
жизни заставило бы искать новую линзу с нужными свойствами или ее 
изготовить. 

Очень важно, что мы отводим время на проектирование восприимчивого 
и дружественного интерфейса пользователя. 

Большая библиотека классов 

Проектирование интерфейса пользователя — это независимая от прило¬ 
жений технология, для которой были разработаны несколько весьма эффек¬ 
тивных библиотек компонентов программного обеспечения многократного ис¬ 
пользования. Существуют такие коммерческие продукты, как MIT’s X 
Window System [4], Open Look [5], Microsoft’s Windows [6], IBM’s 
Presentation Manager [7]. Все системы управления окнами отличаются друг 
от друга: одни ориентированы на сети, другие — на ядро операционной сис¬ 
темы; в одних отдельные точки растра считаются наиболее простым графи¬ 
ческим элементом, в других же используются абстракции высокого уровня, 
такие, как прямоугольники, овалы, дуги. В любом случае все эти продукты 
предназначены для одной цели — упростить задачу реализации той части 
приложения, которая образует интерфейс человек-машина. Следует отметить, 
что ни один из этих продуктов не появился в один день. Наиболее эффек¬ 
тивные системы управления окнами были созданы лишь через определенное 
время из небольших, испытанных систем. Потребовались годы успехов и не¬ 
удач в поиске ряда важнейших абстракций, прежде чем возникла индустрия 
построения интерфейсов пользователя. Мы имеем несколько различных моде¬ 
лей систем управления окнами, так как нет единственно правильного вари¬ 
анта решения проблемы интерфейса пользователя. 

Как и Smalltalk, Object Pascal имеет обширную библиотеку классов, 
представленную в форме Apple’s МасАрр [8]. Apple характеризует МасАрр 
как «интегрированную систему построения объектно-ориентированных прило¬ 
жений» [9]. Итак, МасАрр — это нечто большее, чем система управления 
окнами, она обеспечивает классы для построения окон, объектов отображе¬ 
ния, диалогов и управления, а также содержит классы, представляющие ко¬ 
манды, документы и целые приложения. Проще говоря, МасАрр состоит из 
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определенного числа классов и общедоступных процедур, которые реализуют 
большую часть общего поведения, необходимого для построения приложения, 
соответствующего Стандарту интерфейса пользователя Macintosh [10]. В 
действительности МасАрр делает сложным — хотя вполне возможным — по¬ 
строение приложений, которые нарушают этот Стандарт. 

МасАрр включает большое количество исходных текстов. Ее реализация 
в Object Pascal превышает 40.000 строк исходных текстов, распределенных в 
объектно-ориентированных библиотеках (которые содержат различные классы 
и глобальные определения) и в нескольких библиотеках, не являющихся 
объектно-ориентированными (которые содержат различные общедоступные 
процедуры, поддерживающие такие общедоступные средства, как управление 
меню и распределение памяти). Кроме этих библиотек, существует более 
шестидесяти программных модулей, предназначенных именно для Object 
Pascal, которые обеспечивают доступ к программам пакета разработчика 
Macintosh и другим общедоступным средствам. Диаграмма классов для 
МасАрр показана на рис. 9-2 (представлены только отношения наследования 
между всеми этими классами). Обратите внимание, что базовый класс в 
МасАрр называется TObject, и из этого класса определяются подклассы воз¬ 
растающей специализации. По взаимной договоренности все классы в 
МасАрр названы T<sometting>, чтобы отличать их от простых Pascal -типов. 

Тот, кто впервые работает с МасАрр, часто испытывает трудности, 
связанные с большим числом классов. Что представляют эти классы? Как 
они работают вместе? Как их можно использовать в проблемно-зависимой 
области? Какие классы действительно важны, а какие можно опустить? На 
эти вопросы мы должны ответить, прежде чем использовать МасАрр для по¬ 
строения какого-либо нетривиального приложения. К счастью, необязательно 
знать все нюансы такой большой библиотеки, как МасАрр, так как при 
программировании на языке высокого уровня не надо понимать, как работа¬ 
ет микропроцессор. 

Действительно, трудный момент в обращении с любой большой интегри¬ 
рованной библиотекой классов — это изучение того, какие механизмы она 
содержит. Чем больше вы знаете о ее механизмах, тем проще найти новые 
методы использования уже существующих компонентов вместо того, чтобы 
что-то изобретать на голом месте. На практике, как мы заметили, разработ¬ 
чики обычно начинают с использования наиболее явных классов библиотеки. 
Когда они выходят на определенный уровень абстракций, они все больше 
приближаются к использованию более сложных классов. В конце концов 
разработчики могут найти какую-то свою схему работы со встроенным клас¬ 
сом и добавить ее к библиотеке как примитивную абстракцию. Группа раз¬ 
работчиков может заметить, что определенные проблемно-зависимые классы 
часто появляются в системах, они их тоже включают в библиотеку классов. 

Именно так со временем увеличиваются библиотеки классов — не в 
один день, а постепенно. 

Анализ основных механизмов МасАрр 

Мы не преследуем цель — предложить исчерпывающее руководство по 
МасАрр. Тем не менее мы должны разработать концептуальную интегриро¬ 
ванную систему для МасАрр таким образом, чтобы можно было использо¬ 
вать ее классы в виде основы для проектирования инструментальной систе¬ 
мы разработки конструкций геометрической оптики. 
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Рис. 9-2. Диаграмма классов МасАрр. 

Классы, показанные на рис. 9-2, охватывают значительную часть пове¬ 
дения, общего для приложений, которые соответствуют Стандарту интерфей¬ 
са пользователя Macintosh. Классы МасАрр обеспечивают набор стандартных 
деталей, таких, как, линейка прокрутки, команды отмены и повторного дей¬ 
ствия, группы кнопок, подокна для просмотра внутри окна, управление ме¬ 
ню. В МасАрр имеется много исходных текстов для вывода изображений, 
редактирования текста и вывода документов в файл. Например, используя 
МасАрр, разработчик должен только ввести имена всех элементов данного 
меню, их эквиваленты на клавишах клавиатуры (если таковые имеются), 





Object PascaL Геометрическая оптика 


261 


состояние каждого элемента меню (например, может или не может выпол¬ 
няться) и действие, которое должно быть выполнено, когда пользователь вы¬ 
бирает данный элемент. Остальные действия МасАрр выполняет (даже для 
иерархических меню), включая управление, перемещение графического кур¬ 
сора мыши, отмену выбора меню и вызов соответствующего действия для 
выбора меню. Основное внимание разработчик должен сконцентрировать на 
том, чтобы дополнить систему проблемно-зависимым поведением путем со¬ 
здания новых классов, которые заменяют существующие методы или добав¬ 
ляют новые методы и поля, вместо того чтобы беспокоиться о неприятных 
моментах, связанных с использованием вызовов нижнего уровня из пакета 
разработчика Macintosh. 

Большинство классов, показанных на рис. 9-2, являются абстрактными 
классами. Поэтому разработчик вряд ли будет создавать экземпляр встроен¬ 
ного в МасАрр класса, вместо этого он создаст только экземпляры подклас¬ 
сов. Во всех наиболее важных случаях (например, для класса TApplication) 
МасАрр выдает сообщение об ошибке, если некоторые методы не заменены. 

Чтобы использовать МасАрр для создания нетривиального приложения, 
мы должны понять каким образом работают следующие механизмы: 

* Изображение подобъектов в объекте отображения. 

* Перемещение графического курсора и отклик на действия мыши. 

* Отклик на команды меню. 

* Отклик на событие. 

* Сохранение и восстановление состояния приложения в документе. 

Эти механизмы формируют центральные понятия МасАрр. Многие дру¬ 
гие механизмы также важны для вывода на печать, удаления, копирования, 
чистки, вставки, взаимодействия с пользователем в итерактивном режиме, 
восстановления отказа и распределения памяти, но лучше всего их рассмат¬ 
ривать в контексте всего приложения. 

Изображение подобъектов в объекте отображения. На рис. 9-3 мы ви¬ 
дим весьма типичное для Macintosh окно, которое разбито на шесть объек¬ 
тов отображения: собственно окно (window), палитру (palette), две линейки 
прокрутки (scrollbar), окно просмотра (scroller) и отображение некоторой мо¬ 
дели. Данная иерархия является классическим примером отношения: 
подобьект отображения (subvier) — надобъект отображения (superview). В 
частности, отображение модели является подобъектом отображения окна про¬ 
смотра, которое в свою очередь является подобъектом отображения окна. 
Аналогично палитра, горизонтальная линейка прокрутки и вертикальная ли¬ 
нейка прокрутки являются прямыми подобьектами отображения окна. 

Структура классов этих объектов формирует другую иерархию. Напри¬ 
мер, окно является экземпляром подкласса класса TWindow, который сам 
является подклассом класса TView. В конечном счете TView является супер¬ 
классом всех шести объектов. 

МасАрр не накладывает ограничений на формирование структурной вло¬ 
женности объектов отображения. Это в свою очередь обусловлено тем, что 
класс TView включает следующие два поля: 

* fSuperView Объект отображения, в который помещен данный объ¬ 

ект отображения 

Список всех объектов отображения, которые содержат¬ 
ся в данном объекте отображения 


fSubViews 



262 


Применения 



Рис. 9-3. Структурная иерархия окна. 

Так как каждый объект отображения, изображаемый на экране, в ко¬ 
нечном счете является потомком класса TView, то все такие объекты насле¬ 
дуют эти два поля. 

По соглашению в МасАрр поле каждого класса называется f<something>. 
В отличие от Smalltalk язык ObjectPascal является строго типированным, 
следовательно, каждое поле должно быть объявлено как экземпляр опреде¬ 
ленного класса или как простой Pascal -тип. Классами упомянутых выше 
двух полей являются соответственно TView и TList. Так как Object Pascal 
допускает простой полиморфизм, действительный объект, на который указы¬ 
вает поле, может быть либо непосредственным экземпляром объявленного 
класса (или типом) или в более общем случае экземпляром подкласса (или 
подтипом объявленного класса или типа). 

Все поля в Object Pascal неинкапсулированы. Например, если мы имеем 
объект, названный aWindow, любой объект-пользователь, которому доступен 
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этот объект, может обратиться непосредственно к данному из его полей, на¬ 
пример aWindow.fDocument. Более того, в отличие от C++ все методы в 
Object Pascal являются доступными. Использование неинкапсулированных аб¬ 
стракций является менее надежным, потому что оно допускает прямую за¬ 
висимость обьектов-пользователей от реализации нижнего уровня некоторого 
объекта; если реализация объекта изменяется или мы изменяем значение 
определенных его полей, мы не можем использовать семантику любого из 
его обьектов-пользователей. По этой причине мы будем избегать прямых 
ссылок от объекта-пользователя на поля объекта, хотя в некоторых случаях 
удобство оправдывает риск. Объявление методов класса следует за объявле¬ 
нием его полей. В частности, TView имеет широкий, сложный интерфейс: 
существует 92 метода, определенные для данного класса, не говоря уже о 
тех методах, которые унаследованы от его суперкласса TEvtHandler. Нет не¬ 
обходимости показывать полностью интерфейс TView, но будет полезно ука¬ 
зать, что каждая из этих операций может быть отнесена к одной из следу¬ 
ющих категорий: 

* Методы создания/уничтожения. 

* Методы преобразования координат. 

* Методы управления подобъектами отображения. 

* Методы открытия/закрытия/активизации. 

* Методы управления выбором. 

* Методы задания размера. 

* Методы задания расположения. 

* Методы фокусирования. 

* Методы построения изображения. 

* Методы проверки/аннулирования. 

* Методы управления мышью. 

* Методы управления курсором. 

* Смешанные методы. 

* Методы управления буфером вырезанного изображения. 

* Методы вывода на печать. 

* Методы ресурсов. 

* Методы инспектирования. 

Наиболее непростые подклассы класса TView добавляют свои собствен¬ 
ные поля и методы и заменяют следующие семь методов: 

* DoHighlightSelection. 

* Draw. 

* DoSetUpMenus. 

* Fields. 

* DoMouseCommand. 

* DoMenuCommand. 

* DoSetCursor. 

Для класса TStageDirectionsView как подкласса класса TView рассмот¬ 
рим следующий фрагмент исходного текста: 


StageDirectionsView: TStageDirectionsView; 

begin 

new(StageDirectinsView); 

StageDirectionsView.IView (aDocument, anEnclosingView, gZeroVPT, (100, 100), 

SizeFlilPages, SlzeFillPages); 
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Здесь мы вначале создаем новый объект класса TStageDirectionsView, а 
затем инициализируем его, используя данный документ и надобъект отобра¬ 
жения. Третий и четвертый параметры метода TView указывают на располо¬ 
жение на экране объекта отображения и его начальные размеры относитель¬ 
но надобьекта отображения. Последние два параметра указывают, что объект 
отображения имеет переменный размер, округляемый до размера ближайшей 
страницы. 

Объекты отображения не располагаются сами по себе; они в конечном 
счете инкапсулированы внутри некоторого окна. Могут быть созданы окна 
произвольной сложности, но в МасАрр имеются подпрограммы для создания 
двух наиболее общих типов окон: окон с единственным просматриваемым 
объектом отображения и окон с просматриваемым объектом отображения и 
палитрой, подобно тому что изображено на рис. 9-3. Например, при усло¬ 
вии что мы уже имеем объект класса TStageDirectionsView и другой объект 
класса TPaletteView, мы можем создать окно с палитрой следующим обра¬ 
зом: 


aWindow : TWindow; 

begin 

aWindow NewPaletteWindow (kWindowResource, kWantHScrollBar, kWantVScrollBar, 

aDocument, StageDirectionsView, PaletteView, 
kPaletteWidth, kLeflPalette); 


Первый параметр указывает на идентификатор ресурса окна, связанный 
с шаблоном ресурсного файла приложения, который ѵ описывает начальный 
размер окна и появление его на экране. Следующие два параметра устанав¬ 
ливают, что мы хотим иметь окно, содержащее объект отЬбражения, кото¬ 
рый можно просматривать как в горизонтальном, так и в вертикальном на¬ 
правлении. Четвертый, пятый и шестой параметры обозначают документ, 
просматриваемый объект отображения и палитру соответственно. Седьмой 
параметр задает ширину палитры и последний параметр указывает, что эта 
палитра появится с левой стороны окна. 

Побочным результатом действия данного метода является создание ано¬ 
нимного объекта класса TScroller как подобъекта отображения данного про¬ 
сматриваемого объекта отображения и как подобъекта отображения окна. 
Это согласуется с рис. 9-3. Так как просматриваемый объект отображения 
обычно больше, чем объект, который может быть изображен на экране, то 
этот объект отображения заключается в TScroller -объект, который сам явля¬ 
ется подобъектом отображения объекта окно. Класс TScroller включает зна¬ 
ния о линейках прокрутки, так что, когда пользователь выбирает стрелку 
или область линейки прокрутки или перемещает метку линейки прокрутки, 
объект класса TScroller воздействует на просматриваемый объект отображе¬ 
ния, переустанавливая его в видимой части окна. Окна и объекты отображе¬ 
ния создаются не сами по себе, а некоторым другим объектом. Наиболее 
часто окна и их объекты отображения создаются объектами документов, ко¬ 
торые инкапсулируют состояние модели приложения и поэтому лучше зна¬ 
ют, когда создавать окно и его объекты отображений. Таким образом, мы 
имеем четкое разделение понятий: документы знают, когда создавать окна, 
но только окна знают, каким образом они будут созданы. 
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Когда и как объекты, так же как окна и объекты отображения, разру¬ 
шаются в приложении? В отличие от Smalltalk язык Object Pascal не имеет 
средств автоматической чистки памяти. Вместо этого программист должен 
аккуратно вновь использовать память объектов, которые больше не нужны. 
МасАрр выполняет большую часть сложной работы, зная, когда надо убрать 
определенный объект; например, когда документ закрыт или окно удалено с 
экрана. Тем не менее разработчик наделяет каждый класс, который инкап¬ 
сулирует состояние, знанием того, каким образом вновь использовать это со¬ 
стояние. Для осуществления этой задачи в МасАрр используется метод Free, 
определенный в основном классе TObject и, таким образом, доступный во 
всех остальных классах. Например, предположим, что мы объявили поле 
класса TStageDirectionsView с именем fDirections как экземпляр подкласса 
класса TList. Мы должны выполнить метод Free следующим образом: 

procedure TStageDirections.Free; override; 
begin 

fDirections.FreeList; 

Inherited Free; 


Здесь мы сначала освобождаем память, связанную с полем fDirections, 
и затем вызываем соответствующий метод в цепочке объектов суперкласса. 
Такой стиль программирования вполне обычен для приложений, написанных 
на объектно-ориентированных языках программирования; тело метода кратко 
выражено, потому что оно добавляет к суперклассу только описание поведе¬ 
ния, специфичного для класса. Документы знают лучше, когда создать окно, 
но только окна знают то, каким образом они создаются. Аналогично этому 
окна включают знания того, каким образом их изобразить, но не знают, 
когда это нужно сделать. Вместо этого объект-приложение решает, когда 
восстанавливать изображение окна, например когда открывается новый доку¬ 
мент или когда пользователь установит графический курсор на частично за¬ 
крытое окно, нажмет и отпустит клавишу мыши для его активизации. В 
конечном счете объект-приложение осуществляет вызов метода Update обьек- 
та-окна, который в свою очередь вызывает метод DrawContents объекта-окна. 
Результатом действия метода DrawContents является вызов метода Draw для 
самого же объекта-окна, и затем вызов метода DrawContents для каждого из 
его подобъектов отображения. Аналогично изображение строится сверху вниз 
по связям надобъект отображения/подобъект отображения. В результате ре¬ 
курсия охватывает все подобъекты отображения, которые являются частью 
данного окна. 

Метод Draw должен быть переопределен для каждого проблемно-зависи¬ 
мого объекта отображения; например TStageDirectionsView и TPaletteView. В 
классе TView данный метод определен, но при этом не выполняет никакого 
действия, хотя некоторые подклассы имеют текущую реализацию для метода 
Draw, и поэтому они редко переопределяются (например, TScrollbar, кото¬ 
рый изображает на экране стандартную для Macintosh линейку просмотра). 
Обычно каждый проблемно-зависимый класс объектов отображения содержит 
поле, указывающее на объекты, которые должны быть изображены на экра¬ 
не в объекте отображения, представляющего его модель. Такое объединение 
объектов обычно является гетерогенным, т.е. объекты могут принадлежать 
различным классам. Например, на рис. 9-3 объект отображения включает 
кроме текста также и линии (и прямоугольники, и окружности согласно па- 
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литре). В данной ситуации становится полезным полиморфизм: мы можем 
объявить объект класса TList как объединение объектов, каждый из которых 
может принадлежать различным классам, но все они используют общий 
класс, который является предком некоторого подкласса класса TObject; на¬ 
пример, мы можем назвать этот класс TDrawableObject. Исходя из требова¬ 
ний, предъявляемых в Object Pascal к семантике типов, мы должны объя¬ 
вить метод Draw в этом общем подклассе, но затем переопределить его в 
каждом подклассе TDrawable Object для того, чтобы придать специфичное 
для класса поведение. Таким образом, чтобы изобразить объект отображе¬ 
ния, который содержит объединение данных объектов, мы просто применяем 
итерацию к списку и извлекаем метод Draw для каждого объекта, который 
мы в нем найдем. Если нам надо изменить наше приложение, так чтобы 
объект отображения мог изобразить на экране экземпляры новых классов, 
нам не придется изменять реализацию изображения объекта отображения; 
вместо этого нам следует только создать новые подклассы класса 
TDrawableObject. 

На диаграмме объектов, изображенной на рис. 9-4, показаны механизмы 
изображения в МасАрр. Ключевыми объектами в данном механизме, являют¬ 
ся окно, его подобъекты отображения и модель, изображаемая на экране 
каждым подобъектом отображения. Для наших целей мы считаем fSubViewl 
обособленным полем, потому что объект объединения, на который указывает 
данное поле, не может использоваться ни с каким другим объектом, кроме 
самого объекта-окна (хотя в соответствии с ограничениями Object Pascal это 
поле является доступным). Тем не менее содержание данного объединения, 
т.е. подобъекты отображения окна, являются совместно используемыми объ¬ 
ектами, потому что на них могут ссылаться объекты, отличные от родитель¬ 
ского объекта отображения. В частности, каждый отдельный подобъект ото¬ 
бражения обычно является видимым как поле объемлющего документа. По¬ 
добно этому, модель подобъекта отображения является видимой как поле по¬ 
добъекта отображения, которое обычно является совместно используемым, 
так как модель может быть видимой более чем в одном объекте отобра¬ 
жения. 

Диаграмма объектов на рис. 9-4 охватывает статические связи объектов, 
включенных в механизмы изображения МасАрр. Однако вспомним, что диаг¬ 
рамма объектов отражает только какой-то момент постоянно меняющихся 
событий или конфигурации объектов. Такие объекты, как окна и объекты 
отображения, создаются и разрушаются в течение цикла существования про¬ 
граммы, и, следовательно, диаграммы объектов могут отразить только наибо¬ 
лее интересные формы взаимодействия в данном наборе объектов в какой-то 
момент времени. По этой причине мы используем временные диаграммы на 
рис. 9-4, чтобы отразить динамику механизма изображения МасАрр. 

Для того чтобы изобразить содержание объекта-окна, некоторый объект- 
пользователь извлекает метод Update объекта-окна, который в свою очередь 
вызывает метод DrawContents. DrawContents сначала вызывает метод Draw 
для самого объекта-окна, а затем метод DrawContents для каждого подобъек¬ 
та отображения, найденного в объединении fSubViewl. DrawContents для 
каждого подобъекта отображения извлекает метод Draw для этого же подо¬ 
бъекта отображения и затем извлекает DrawContents для каждого из его по- 
добьектов отображения и так далее, пока не останется никаких других по¬ 
добъектов отображения. 

В реализации метода Draw каждого объекта отображения мы находим 
проблемно-зависимое поведение. Например, если объект отображения имеет 
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Рис. 9-4. Механизм изображения в МасАрр. 

поле fModel, которое содержит указатель на гетерогенный список изображае¬ 
мых объектов, то реализация метода Draw объекта отображения обычно 
представляется в виде итерации, коща на каждый объект из данного объе¬ 
динения действует метод Draw. Следует определить отдельные объекты, ко¬ 
торые появляются в объекте отображения, чтобы включить в них знания о 
том, каким образом они должны сами себя изображать, вызывая различные 
QuickDraw программы, но не момент, когда они должны быть изображены. 

Без изменения основных понятий данного механизма мы можем 
существенно повысить его производительность. Как уже говорилось выше, 
модель обычно больше, чем то, что может быть изображено на экране в от¬ 
дельном окне. 

Объект отображения, который содержит такую модель, может быть рас¬ 
ширен до нескольких физических страниц, хотя ограничения, связанные с 
размером экрана, позволяют показать только часть этого объекта отображе¬ 
ния в окне. Поэтому мы вводим класс TScroller. В частности, объект класса 
TScroller отвечает за отображение части изображения, содержащегося в про¬ 
сматриваемом объекте отображения, как правило, в небольшое окно. Таким 
образом, когда мы изображаем большой объект отображения, то нет 
необходимости изображать каждый объект в объекте отображения, так как 
многие из этих объектов не попадают в видимую часть объекта отображе- 







Применения 


ния. Необходимость в оптимизации возникает тогда, когда процесс изобра¬ 
жения объекта становится достаточно сложным и длительным. По этой при¬ 
чине МасАрр передает параметр Area методу Draw. Когда вызывается метод 
Draw для данного объекта отображения, МасАрр в первую очередь определя¬ 
ет прямоугольные координаты области, изображение которой должно быть 
восстановлено. Например, если частично закрытое окно становится активным 
или если объект-пользователь просматривает объект отображения, МасАрр 
может определить минимальную область объекта отображения, которая была 
аннулирована и, следовательно, должна быть восстановлена. Значение разме¬ 
ров данной области передается в метод Draw объекта отображения, так что 
при реализации метода Draw для каждого объекта отображения можно избе¬ 
жать изображения объекта, находящегося вне аннулированной зоны, путем 
первой проверки, которая покажет, действительно ли изображение объекта 
перекрывается значением параметра области. Если это подтверждается, объ¬ 
ект изображается; в противном случае ничего не происходит. 

Проблемно-зависимый объект-пользователь может использовать тот же 
механизм. Например, предположим, что мы имеем приложение, в котором 
пользователь может применять выбранные из палитры сервисные программы 
для добавления, уничтожения и перемещения объектов внутри объекта ото¬ 
бражения. Какой бы объект ни модифицировался в модели объекта отобра¬ 
жения, область, содержащая объект воздействия, должна быть известна объ¬ 
екту отображения путем использования одного из методов аннулирования 
объекта отображения (такого, как метод InvalidRect, определенный в классе 
TView). В результате действия данного метода должны скапливаться области 
объекта отображения, которые устарели и поэтому должны быть восстанов¬ 
лены; параметр области, переданный методу Draw объекта отображения, 
представляет собой объединение всех этих аннулированных областей. 



Рис. 9-5. Механизм действия мыши в МасАрр. 






Object Pascal Геометрическая оптика 


269 


Перемещение графического курсора и реакция на действия мыши. В 
таких приложениях, как инструментальное средство разработки конструкций 
геометрической оптики, предоставляется широкий выбор взаимодействий с 
пользователем. Выше мы говорили, что класс TView является подклассом 
класса TEvtHandler, который содержит знания о том, как реагировать на 
действия мыши. Возвращаясь к рис. 9-3, предположим, что пользователь на¬ 
жал и отпустил клавишу мыши где-нибудь внутри просматриваемого объекта 
отображения, чтобы выбрать абзац для удаления. Механизм, с помощью ко¬ 
торого приложение реагирует на это действие мыши, показан на диаграмме 
объектов на рис. 9-5. 

Из диаграммы мы видим, что событие нажатия клавиши мыши в пер¬ 
вую очередь обнаруживает объект-приложение, используя механизм основно¬ 
го цикла событий, который мы опишем ниже подробно. Событие нажатия 
клавиши мыши может произойти в одном из нескольких положений графи¬ 
ческого курсора на экране: 

* На линейке меню. 

* Вне окна приложения. 

* Внутри контура кнопки, отвечающей за увеличение окна. 

* Внутри контура кнопки, отвечающей за выход из окна. 

* Внутри контура кнопки, отвечающей за увеличение размеров окна до раз¬ 
меров экрана. 

* Внутри содержимого окна приложения. 

Механизм реакции МасАрр на событие нажатия клавиши мыши в поло¬ 
жении графического курсора на линейке меню мы опишем ниже. МасАрр 
автоматически управляет событиями нажатия клавиши мыши в следующих 
четырех положениях графического курсора, хотя текущая реакция может 
быть отменена. Для того чтобы управлять событиями нажатия клавиши мы¬ 
ши в окне приложения, пользователь должен обеспечить проблемно-зависи¬ 
мую обработку этих событий. 

Механизм изображения в МасАрр дает возможность каждому подобьекту 
отображения, который содержится в окне, изобразить самого себя, начиная 
от вершины цепочки надобъект отображения/подобъект отображения и двига¬ 
ясь вниз, пока все объекты отображения не будут использованы. В МасАрр 
механизм действия мыши совсем другой: в нем осуществляется поиск самого 
нижнего объекта отображения в цепочке надобъект отображения/подобьект 
отображения, который пересекается с расположением графического курсора, 
и только этому объекту отображения предоставляется возможность отреагиро¬ 
вать на действие мыши. Как показано на рис. 9-5, если объект-приложение 
обнаруживает, что событие нажатия клавиши мыши происходит, когда гра¬ 
фический курсор находится внутри содержимого окна приложения, то прило¬ 
жение извлекает метод HandleMouseDown для соответствующего объекта-ок¬ 
на. Если это окно не является внешним окном (для простоты это не пока¬ 
зано на временной диаграмме), HandlerMouseDown сначала выбирает окно, 
чтобы сделать его активным. Для того чтобы зафиксировать подобъект ото¬ 
бражения самого низкого уровня, который содержит точку положения графи¬ 
ческого курсора при нажатии клавиши мыши, HandleMouseDown проходит 
по цепочке надобъект отображения/подобьект отображения, используя итера¬ 
тор LastSubViewThat, определенный в классе TView. Так как объекты ото¬ 
бражения могут иметь подобъекты отображения, как в иерархии окно/окно 
просмотра/просматриваемый объект отображения, показанной на рис. 9-5, то 
HandleMouseDown вызывается для каждого вложенного объекта отображения. 
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Если HandleMouseDown достигает подобъекта отображения, который пересе¬ 
кается с расположением графического курсора мыши в момент действия мы¬ 
ши, и если подобьект отображения находится на нижнем уровне цепочки 
над объект отображения/подобъект отображения, то метод DoMouseCommand 
извлекается только для этого объекта отображения. Как только мы встреча¬ 
ем подобъект отображения, который удовлетворяет этим критериям, поиск 
по цепочке надобъект отображения/подобьект отображения сразу же при¬ 
останавливается. Проблемно-зависимое поведение должно быть заложено в 
методе DoMouseCommand в такой же степени, как и в методе Draw для 
механизма изображения МасАрр. В классе TView реализация метода 
DoMouseCommand по существу отсутствует. Способ замены данного метода 
зависит от конкретных требований данной проблемной области. Например, 
если объектом отображения является палитра, обычным действием метода 
DoMouseCommand будет отмена выделения картинки последней выбранной 
сервисной программы и затем выделение картинки сервисной программы, ко¬ 
торая оказывается под графическим курсором. Если объект отображения яв¬ 
ляется просматриваемым объектом отображения, который содержит текст и 
графику (рис. 9-3), то обычно действие мыши представляет собой выбор или 
отмену выбора определенных объектов, начало перемещения всех выбранных 
пользователем объектов или начало применения только что выбранной сер¬ 
висной программы. 

Типичным для МасАрр является то, что метод DoMouseCommand дол¬ 
жен создавать объекты команды в виде посредников для выполнения дейст¬ 
вительной работы. Например, вместо того чтобы действительно перемещать 
выбранные в данный момент объекты, метод DoMouseCommand может со¬ 
здать объект DraggerCommand как экземпляр проблемно-зависимого подклас¬ 
са класса TCommand. Создание посредников команды намного выгоднее, чем 
выполнение работы непосредственно в объекте отображения. Во-первых, это 
обеспечивает большее разделение функций, позволяя объектам отображения 
сосредоточиться на изображении и обнаружении событий, а объектам-коман¬ 
дам сосредоточиться на выполнении, изменении и отмене действий. Во-вто¬ 
рых, мы достигаем более высокой степени многократного использования и 
таким образом пишем меньше исходных текстов: поведение, заключенное в 
объектах-командах, часто необходимо как для механизма команд меню, так 
и для механизма действия мыши. В-третьих, данный подход является более 
гибким. Например, если бы мы захотели изменить визуальную обратную 
связь во время перемещения выбранных объектов, то нам не пришлось бы 
изменять каждый класс объектов отображения, но, вероятно, мы должны 
были бы модифицировать определенные методы объекта-команды. 

Отклик на команды меню. Когда приложение обнаруживает, что нажа¬ 
тие клавиши мыши произошло в положении графического курсора внутри 
линейки меню, то МасАрр реагирует на это с помощью механизма команд 
меню. Данный механизм не может использовать те же отношения надобъект 
отображения/подобьект отображения, какие использует механизм действия 
мыши, в первую очередь потому, что всем объектам, отличным от объектов 
отображения и окон, должна быть предоставлена возможность реагировать 
на определенные команды меню. В частности, объекты отображения и окна 
ничего не знают о том, как открываются и закрываются документы, но до¬ 
кументы и приложения знают это; таким образом они должны участвовать 
в механизме команд меню. Механизм команд меню использует абстракцию, 
называемую цепочкой команд, изображенной на диаграмме объектов на рис. 
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Рис. 9-6. Механизм команд меню в МасАрр. 

9-6. При формировании цепочки команд используется поле fNextHandler, 
определенное в классе TEvtHandler. Таким образом, каждый подкласс 
TEvtHandler, включающий объекты отображения, документы и приложения, 
имеет данное поле. Всякий раз, коща такой объект инициализируется, в 
МасАрр строится цепочка команд. В частности, каждый подобъект отображе¬ 
ния указывает на свой надобъект отображения, каждое окно — на доку¬ 
мент, содержащийся в нем, каждый документ — на свой объект-приложе¬ 
ние. Таким образом, цепочка команд представляется значительно более 
сложной, чем список надобъект отображения/подобъект отображения. Эта це¬ 
почка включает не только объекты, отличные от объектов отображения и 
окон, но, кроме того, на каждый объект-приложение могут ссылаться состав¬ 
ные документы, на каждый документ — составные окна и на каждое 
окно — составные объекты отображения. 

Целью формирования цепочки команд является объединение объектов, 
которые могут реагировать на команды меню и упорядочены по их наилуч¬ 
шему положению для выполнения действия. Сначала идут конкретные подо¬ 
бъекты отображения, за ними следуют их надобъекты отображения, затем 
окно, в котором они содержатся, затем их документ и в конце следует их 
объект-приложение. Отметим, что цепочка начинается не с объекта-приложе¬ 
ния, а с объекта значительно более низкого уровня. Головной объект цепоч¬ 
ки содержится в глобальной переменной gTarget (по соглашению в МасАрр 
все глобальные переменные называются g<something>) . Всякий раз, когда ак- 
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тивизируется окно, в gTarget обычно помещается такой подобьект, который 
является наиболее интересным для команды меню. Для окна, которое вклю¬ 
чает составные подобьекты отображения, объект-пользователь указывает на 
этот подобьект отображения, когда создается окно. Общедоступная процедура 
NewPalleteWindow, например, указывает на просматриваемый объект отобра¬ 
жения как на наиболее интересный для команды меню. В связи с этим не¬ 
которым объектам отображения обычно не предоставляется возможность уча¬ 
ствовать в цепочке команд. Например, объект отображения «палитра», веро¬ 
ятно, никогда не будет частью цепочки команд, так как он почти не 
реагирует на какую-либо команду меню. 

Когда нажатие клавиши мыши произошло на линейке меню, то метод 
HandleMouseDown объекта-приложения сначала вызывает программу Menu- 
Select из Пакета разработчика Macintosh для того, чтобы определить, какие 
были выбраны меню и его элемент. Данная общедоступная процедура пере¬ 
мещает графический курсор мыши, выделяет все элементы меню, спускает 
вниз меню и в конце возвращается к прежнему состоянию, когда отпускает¬ 
ся клавиша мыши. Если пользователь отпустил клавишу внутри элемента 
меню, объект-приложение вызывает, свой метод MenuEvent, для того чтобы 
определить, какое меню и в какой элемент были выбраны, и закодировать 
данную пару меню/элемент пару единственным числом, называемым коман¬ 
дным числом. Как показано на рис. 9-6, приложение затем вызывает метод 
DoMenuCommand для объекта, указатель на который содержится в глобаль¬ 
ной переменной gTarget. Если данный объект не имеет возможности отреа¬ 
гировать на команду, такое же сообщение посылается следующему объекту в 
цепочке. Этот процесс продолжается до тех пор, пока не будет найден объ¬ 
ект, который сможет отреагировать на команду меню, либо fNextHandler не 
окажется нулевым (что в МасАрр является текущей 'величиной для данного 
поля для всех объектов-приложений). 

Пользователь должен поработать с методом DoMenuCommand для того, 
чтобы вложить в него проблемно-зависимое поведение. Обычно реализация 
данного метода представляется большим количеством операторов выбора: 

begin 

DoMenuCommand gNoChanges; 
case ACmdNumber is 
cSelectAll: 
cCut: 
cCopy: 
cPaste: 
cClear: 
kDrawingSize: 

otherwise DoMenuCommand Inherited DoMenuCommand(ACmdNumber); 


В МасАрр все командные константы именуются c<something>, а другие 
типы констант — k<something>. Мы решили именовать все проблемно-зави¬ 
симые константы как k<something>. 

Команда DoMouseCommand должна проверять, какие еще команды мо¬ 
гут правильно управляться всеми объектами заданного класса. Например, 
просматриваемый объект отображения должен иметь возможность отреагиро¬ 
вать на команды выбора, вырезания, копирования, вставки, чистки и изме¬ 
нения размера изображения. Документ, с другой стороны, должен только от- 
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реагировать на команды вывода на печать, сохранения и возвращения. Если 
указанный объект не может управлять командой, как показано в предшест¬ 
вующем исходном тексте, то надо просто вызвать соответствующий метод в 
суперклассе. Если суперкласс не может отреагировать на данную команду, 
то же самое делается с его суперклассом и т.д. Предположим, что мы не 
нашли промежуточный суперкласс, который может отреагировать на команду 
меню. Управление в итоге достигает метода, определенного в классе 
TEvtHandler, в котором реализован вызов метода DoMenuCommand для сле¬ 
дующего объекта в цепочке команд. Таким образом, прохождение по цепоч¬ 
ке заканчивается, когда мы достигаем объекта, чье поле fNextHandler имеет 
нулевое значение (которое является обычной величиной устанавливаемой в 
объекте-приложении). Редко прохождение по цепочке достигает конца, пото¬ 
му что это означало бы, что мы имеем команду, для которой не существу¬ 
ет реагирующего на нее объекта. 

Имея такой механизм, проектировщик может сконцентрироваться на 
желаемом проблемно-зависимом поведении для каждого класса и быть 
уверенным в текущем поведении для всех общих команд, ..таких, как вывод 
на печать, открытие, закрытие и сохранение документов. Так же как и для 
механизма действия мыши, мы обычно предполагаем для метода 
DoMenuCommand возможность создавать объекты-команды как посредники, 
которые выполняют действительную работу, хотя, с другой стороны, имеется 
альтернатива выполнять работу на месте. Мы обычно не создаем объекты- 
команды для простых действий, таких, как выбор; мы используем их для 
сложных действий, таких, как вырезание, копирование, вставка и чистка. 
Если мы хотим иметь возможность отменять или выполнять заново дейст¬ 
вие, лучше всего создавать объект-команду. Если мы хотим использовать- 
действие в других местах или если действие особенно сложное, мы также 
должны создать объект-команду. 

Стандарт интерфейса пользователя Macintosh разрешает иметь эквива¬ 
ленты элементам меню на клавиатуре. Например, комбинация командных 
клавиш клавиатуры Command-x обычно обозначает элемент Cut в меню 
Edit. При реакции на нажатие командной клавиши клавиатуры повторно ис¬ 
пользуется механизм команд меню. В частности, когда приложение обнару¬ 
живает комбинацию командных клавиш клавиатуры, вызывается метод 
DoCommandKey вдоль всей цепочки команд. В текущей реализации метод 
DoCommandKey ничего не выполняет, но при этом происходит переход уп¬ 
равления к следующему объекту так, что управление в итоге достигает объ¬ 
екта-приложения, который включает перекодировку командного числа в пару 
меню/элемент и затем вызывает метод DoMenuCommand, начиная с gTarget 
и используя командное число. При реакции на команды клавиатуры, отли¬ 
чающиеся от комбинации командных клавиш клавиатуры, также использует¬ 
ся цепочка команд. В этом случае приложение вызывает метод 
DoKeyCommand, который применяется к объекту, указатель, на который со¬ 
держится в gTarget. 

Отклик на событие. Существует восемь внешних событий, на которые 
может реагировать приложение МасАрр: 

* Клавиша мыши отпускается. 

* Клавиша мыши нажимается. 

* Окно активизируется. 

* Окно обновляется. 

* Клавиша клавиатуры нажимается. 

18 Гради Буч 
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* Диск. 

* Система. 

* Alien. 

Многие из этих событий автоматически управляются МасАрр. В частно¬ 
сти, МасАрр обнаруживает и реагирует на события активизации и события 
обновления окна, события вставки и удаления диска, MultiFinder -события и 
сетевые события. Событие, связанное с отпусканием клавиши мыши, обычно 
игнорируется приложениями, кроме тех случаев, когда пользователь переме¬ 
щает мышь, два или три раза быстро нажимает клавишу, или отпускает 
клавишу мыши над определенными объектами управления. 

МасАрр обнаруживает все эти события как часть механизма главного 
цикла событий. Этот механизм выступает в качестве общепринятой структу¬ 
ры для большинства приложений с однородным интерфейсом, т.е. таких 
приложений, в которых на порядок взаимодействия пользователя с системой 
мы накладываем мало ограничений. В данном механизме главная нить уп¬ 
равления для приложения состоит из цикла, в течение которого мы сначала 
либо получаем, либо ожидаем событие. Если событие обнаружено, мы вызы¬ 
ваем соответствующую операцию для управления им. Цикл завершается 
только тогда, когда пользователь выходит из приложения. 

В МасАрр экземпляры класса TApplication действуют как посредники, 
отвечающие за механизм событий главного цикла. Поэтому, вместо того 
чтобы строить структуру корня нашего приложения, как если бы она нахо¬ 
дилась на вершине алгоритмической декомпозиции, мы в первую очередь 
используем главную программу для объявления экземпляров подкласса 
TApplication, а затем вызываем его метод Run (который в конечном счете 
выводит действие из главного цикла). Преимущество использования объекта- 
приложения по сравнению с применением алгоритмической абстракции в 
корне приложения заключается в том, что это дает нам последовательную 
концептуальную модель, так как все остальное в нашем приложении состоит 
из наборов совместно работающих объектов. 

Как мы уже говорили в гл. 3, мы при проектировании обычно создаем 
классы, которые экспортируют примитивы. По этой причине в метод Run не 
заключается непосредственно исходный код для механизма главного цикла; 
его работа разделяется по нескольким методам. Это позволяет разработчику 
легко подгонять текущее поведение объекта-приложения. Короче говоря, ре¬ 
зультатом действия метода Run является вызов метода MainEventLoop. При 
каждом проходе через цикл MainEventLoop сначала вызывает метод 
PollEvent объекта-приложения, который ищет новые события. Если событие 
найдено, MainEventLoop вызывает метод GetEvent для получения всей ин¬ 
формации о событии и затем вызывает метод HandleEvent. HandleEvent в 
свою очередь вызывает метод DispatchEvent объекта-приложения, который 
посылает метод (такой, как HandleMouseDown) , соответствующий определен¬ 
ному типу события. 

Приложения, в которых преобладает взаимодействие человек/машина, 
часто включают относительно длинные периоды времени в течение которых 
в приложении ничего не выполняется. Пользователь часто тратит много 
времени, думая о том, что ему делать дальше. В течение этого времени 
большие компьютерные циклы являются пустыми. Для того чтобы позволить 
приложению выполнять полезную работу в течение этих холостых периодов, 
механизм главного цикла события применяет холостую цепочку. Холостая 
цепочка является простым списком объектов, каждый из которых является 
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экземпляром некоторого подкласса класса TEvtHandler. Глобальная перемен¬ 
ная содержит указатель на заголовок данного списка, и объекты связывают¬ 
ся через поле fNextHandler, как определено в классе TEvtHandler. То же 
поле используется для формирования цепочки команд, но так как цепочка 
команд и холостая цепочка являются ортогональными концепциями, данный 
объект никогда не появляется в обеих цепочках одновременно. 

Если нет ждущих событий, механизм события главного цикла проходит 
по холостой цепочке, вызывая метод Doldle для каждого объекта, который 
он встречает, так что этот объект всякий раз, когда он пожелает, может 
выполнить проблемно-зависимую обработку. Каждый объект в цепочке также 
имеет поле fldleFreq (определенное в классе TEvtHandler), которое указыва¬ 
ет, как часто метод Doldle должен вызываться. Например, если в приложе¬ 
нии требуется объект отображения с несколькими мигающими элементами, 
то мы, вероятно, захотим, чтобы соответствующий метод Doldle вызывался 
только через каждые несколько интервалов таймера, а не каждый холостой 
цикл. 

Сохранение и восстановление состояния приложения в документе. 
Пользователю инструментального средства построения конструкций геометри¬ 
ческой оптики должна предоставляться возможность создавать эксперименты, 
манипулировать ими и сохранять их для дальнейшего использования. Тем 
не менее МасАрр не включает ничего-слишком сложного, подобно объектно- 
ориентированной базе данных, и поэтому непосредственно не поддерживает 
постоянство объектов. Вместо этого мы должны использовать другой меха¬ 
низм, чтобы обеспечить иллюзию постоянства. 

МасАрр использует класс TDocument для сохранения состояния прило¬ 
жения. Теоретически документ служит в виде гетерогенного хранилища не¬ 
которых объектов-приложений, которые нужно сохранить между реализация¬ 
ми. Например, документ для инструментального' средства разработки конст¬ 
рукций геометрической оптики должен представлять единственный оптиче¬ 
ский эксперимент, состоящий из всех линз, расположенных вдоль оптиче¬ 
ской скамьи. Документ также должен сохранять состояние характеристик 
приложения, выводимых на печать, заметок пользователя или расположения 
и размер всех активных в настоящий момент окон. 

Хотя TDocument является подклассом класса TEvtHandler, он добавляет 
несколько новых полей, таких, как fTitle (свое имя), fWindowList (список 
окон, принадлежащих документу) и fChangeCount (число изменений в состо¬ 
янии документа с момента его последнего сохранения). Обычно вместо ис¬ 
пользования класса определяется его подкласс, который включает также по¬ 
ле для каждого значительного подобъекта отображения и поле, которое ука¬ 
зывает на постоянное состояние документа. Мы связываем это состояние 
скорее с документом, чем с объектом отображения, который изображает его 
на экране, потому что объекты отображения имеют временный характер, 
тоща как документы существуют в течение значительного времени жизни 
модели. Так как эта же модель часто разделена на более чем один объект 
отображения, то помещение модели вместе с ее документом обеспечивает 
устойчивую точку ссылки для каждого временного объекта отображения. 

В МасАрр программа может иметь только один объект-приложение, хотя 
каждый объект-приложение может использовать несколько, возможно, раз¬ 
личных объектов-документов. Объект-документ обычно создается всякий раз 
при запуске приложения или когда пользователь выбирает New- или Ореп- 
элементы меню в стандартном File меню. В результате каждое из этих дей¬ 
ствий кончается обращением к методу DoMakeDocument поиложения. Про- 
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Рис. 9-7. Механизм документа в МасАрр. 

блемно-зависимая реализация данной функции должна быть обеспечена в 
подклассе класса Т Application, и она обычно осуществляется довольно 
просто: объект-документ создается, инициализируется и затем возвращается 
в виде значения функции. 

На рис. 9-7 иллюстрируется механизм документирования МасАрр, с по¬ 
мощью которого постоянное состояние документа восстанавливается. Этот 
механизм начинает работать после того, как соответствующий объект-доку¬ 
мент создается в методе DoMakeDocument. Когда пользователь открывает су¬ 
ществующий документ, либо выбирая Ореп-элемент меню в File -меню, либо 
открывая документ из Macintosh Finder, вызывается метод OpenOld объекта- 
приложения. Этот метод вызывает метод ReadFromFile, определенный в 
классе документов. Если физический файл, именуемый документом, может 
быть открытым, то ReadFromFile вызывает метод документа DoRead, кото¬ 
рый мы должны выполнить для каждого подкласса класса TDocuraent. 

Рассмотрим подкласс TStageDirectionsDocument, содержащий поле 
fDirections, которое представляет постоянное состояние документа. Сначала 
мы должны определить метод DoRead для данного объединения, которое мы 
можем использовать следующим образом: 

procedure TStageDirectionsDocument.DoRead (ARefNum : Integer; 

RsrcExists, 


ForPrinting : Boolean); override; 
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begin 

inherited DoRead(ARefNum, RsrcExists, ForPrinting); 
fDirections.DoRead (ARefNum); 

end; 


Мы вызываем унаследованный метод DoRead, чтобы дать МасАрр воз¬ 
можность прочитать его состояние (такое, как выбор принтера). Так как со¬ 
стояние документа обычно включает объединение гетерогенных объектов, то 
при сохранении документа должен кодироваться класс каждого объекта перед 
регистрацией его состояния. Если метод DoRead поля fDirections вызывается, 
его действие может быть представлено следующим образом: 

<read a value indicating the number of objects that fo!low> 
for Index 1 to Count do 

<read a value indicating the class of the object that follows> 

<clone a copy of an object of this class> 

AnObject.DoRead (ARefNum); 

end; 


Данный подход аналогичен механизму изображения, в котором действи¬ 
тельная работа в конечном счете выполняется объектами самого нижнего 
уровня. Как мы увидим ниже, парадигма имитации объектов из прототипов 
полезна и может быть использована для создания других объектов, таких, 
как общедоступные процедуры, определенные в палитре. 

Здесь, мы рассмотрели только наиболее общие классы в МасАрр. На¬ 
пример, мы еще не изучали класс TEView с его подклассами и механизма¬ 
ми, которые вместе обеспечивают характеристики простого текстового редак¬ 
тора, поддерживающего многочисленные шрифты, изменение размеров и раз¬ 
личные стили. Мы не изучали механизмы, заключенные в классе 
TGridView, классы, поддерживающие отладку и восстановление ошибок; не 
были представлены классы, связанные с диалогами. Различия между диало¬ 
гом и простым окном становятся расплывчатыми в МасАрр. Кроме того, 
представленные ниже простые механизмы являются основными частями для 
всех этих классов. Это не удивительно, и как мы уже говорили в гл. 1, 
системы, имеющие сложное поведение, часто конструируются из нескольких 
относительно простых механизмов. Это в определенной степени верно для 
МасАрр. Мы должны указать также, что существуют ограничения при ис¬ 
пользовании МасАрр. В частности, действительные методы управления па¬ 
мятью в МасАрр ограничивают число объектов, которые могут быть созданы 
в приложении, лишь несколькими тысячами в зависимости от сложности 
каждого объекта. Поскольку МасАрр пригоден для реализации таких прило¬ 
жений, как инструментальное программное средство разработки конструкций 
геометрической оптики, другие методы должны быть использованы для таких 
приложений, как инструментальные средства машинного проектирования или 
программы моделирования геометрических тел, которые могут содержать де¬ 
сятки тысяч объектов. Это не означает, что мы должны отказаться от объ¬ 
ектного подхода или отказаться полностью от использования МасАрр; это 
означает только, что мы иногда должны полагаться на смешанное проекти¬ 
рование. В частности, вместо того чтобы трактовать каждый концептуальный 
объект как конкретный экземпляр подкласса класса TObject, мы должны ис¬ 
пользовать простые типы Pascal для формирования модели приложения, хотя 
мы должны еще иметь возможность использовать классы МасАрр для фор¬ 
мирования интерфейса пользователя. 
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Рис. 9-8. Модульная архитектура ObjectPascal. 

9.2. ПРОЕКТИРОВАНИЕ 
Модульная архитектура 

Декомпозиция приложений Macintosh. В Smalltalk класс — единственно 
возможный элемент декомпозиции. Хотя программа просмотра системы в 
Smalltalk позволяет привязать классы к различным категориям, эта концеп¬ 
ция применима далеко не во всех случаях, так как она не ограничивает 
видимость класса внутри группы. Следовательно, все классы, объявленные в 
среде Smalltalk, глобально видимы. Для малых систем это не имеет особого 
значения, но с переходом к более крупным приложениям мы достигаем 
уровня, на котором отсутствие модульной структуры делает наш проект 
очень трудным для понимания. Без средств группировки абстракций в боль¬ 
шие структуры мы быстро достигаем пределов человеческих способностей по¬ 
нимать одновременно множество различных предметов. 

К счастью, Object Pascal дает структуру для декомпозиции больших си¬ 
стем в отдельные модули, позволяя нам скрыть определенные классы и объ¬ 
екты друг от друга и уменьшить общие зависимости абстракций. Это осо¬ 
бенно важно в строго типированном языке. Если не уменьшить зависимости 
абстракций друг от друга, то мы будем вынуждены постоянно рекомпилиро- 
вать почти всю систему при внесении малейших изменений. В больших сис¬ 
темах, находящихся в процессе разработки, это может существенно повлиять 
на графики разработки и даже затруднить внесение изменений. Использова¬ 
ние модулей для группировки абстракций и решения вопроса о видимости в 
конечном счете укрепляет нашу уверенность в стабильности и корректности 
систем. 



Рис. 9-9. Модульная диаграмма инструментального средства 
разработки конструкций геометрической оптики. 

В Object Pascal синтаксическая структура модуля называется программ¬ 
ным модулем. Программный модуль имеет две части — интерфейс и реали¬ 
зацию. Интерфейс программного модуля может содержать только константы, 
типы, переменные,, функциональные и процедурные спецификации, а любые 
методы или общедоступные процедуры в интерфейсе программного модуля 
должны быть завершены в его реализации. Итак, интерфейс дает внешнее 
представление об абстракции, а его реализация содержит внутреннее пред¬ 
ставление. 

В реализацию программного модуля могут быть помещены объявления, 
но они видимы только в реализации данного конкретного программного мо¬ 
дуля и, следовательно, скрыты от других. В частности, мы можем объявить 
класс в реализации программного модуля так, чтобы он не мог быть отне¬ 
сен к какому-либо другому программному модулю. И наоборот, любые объ- 
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явления, помещенные в интерфейс программного модуля, видимы в реализа¬ 
ции этого программного модуля, а также во всех программных модулях, ис¬ 
пользующих данный программный модуль. Эти моменты показаны на 
рис. 9-8. Если реализация программного модуля С требует объявления D, то 
С должен использовать D. В отличие от Ada в Object Pascal зависимости 
представлены только в интерфейсе программного модуля, даже если исполь¬ 
зованный программный модуль необходим только для реализации. Предполо¬ 
жим, что метод, объявленный в интерфейсе программного модуля В требует 
обозначения класса или типа, объявленного в интерфейсе программного мо¬ 
дуля С. В должен использовать С, но не должен использовать программный 
модуль D. Если интерфейс программного модуля А должен иметь доступ к 
объявлениям из интерфейса программного модуля В, то А тоже должен ис¬ 
пользовать В. Однако, так как интерфейс В зависит от С, программный мо¬ 
дуль А должен также использовать программный модуль С. 

В МасАрр представлена вторая модульная структура, необходимая для 
Macintosh. В частности, каждое приложение состоит из двух частей: ветвле¬ 
ния данных и ветвления ресурсов. Документы, связанные с приложением, 
как правило, используют ветвление данных для сохранения своего состояния. 
Приложения же обычно используют только ветвление ресурсов для сохране¬ 
ния своего кода, а также других ресурсов, таких, как меню, шрифты, пик¬ 
тограммы, изображения и шаблоны окон. Преимущество этих ресурсов состо¬ 
ит в том, что они позволяют менять внешний вид приложения без переком¬ 
пилирования кода исходного текста. Например, предположим, мы первона¬ 
чально написали программу, предполагая, что ее будут использовать только 
те, кто владеет английским языком, а теперь мы хотим распространить вер¬ 
сию этого приложения во Франции и в Японии. Если мы уже жестко зако¬ 
дировали имена пунктов меню или текст в диалоговых окнах, то нам при¬ 
дется изменить код исходного текста и все перекомпилировать. Это не толь¬ 
ко прибавит проблем в управлении конфигурацией системы и в контроле 
версий, но также уменьшит нашу уверенность в корректности каждой новой 
версии, так как по неосторожности мы могли внести изменения в какую-ли¬ 
бо одну версию, а в другие нет. Если вместо этого мы поместим эти ресур¬ 
сы в ресурсный файл, нам придется всего лишь модифицировать ресурсы 
приложения для изменения его внешнего вида без воздействия на код ис¬ 
ходного текста. 

Как наличие этих модульных структур отражается на нашем проекте? 
Мы можем просто не обращать на них внимания и объявить все в одном 
программном модуле. Это не очень хорошая идея, так как она не учитыва¬ 
ет проблемы видимости, с которой мы сталкиваемся в Smalltalk. Мы могли 
бы использовать другую возможность и поместить каждый класс в отдель¬ 
ный программный модуль. Это тоже не будет оптимальным вариантом: боль¬ 
шие системы будут содержать сотни, если не тысячи таких программных 
модулей, что сделает весьма затруднительным даже нахождение интересую¬ 
щих нас классов. Более того, с помещением классов в отдельные программ¬ 
ные модули значительно возрастает сложность системы, потому что 
приходится распутывать очень сложное переплетение зависимостей программ¬ 
ных модулей. 

Приемлемый ответ находится где-то посередине, между этими двумя 
крайностями, а методика, изложенная в гл. 4, может помочь нам прийти к 
хорошо разработанной модульной декомпозиции. На практике мы убедились, 
что наилучшим решением является создание модулей, организованных вок- 
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руг значимых объединений классов и объектов. Под значимыми мы понима¬ 
ем такие объединения, где каждая абстракция в группе более тесно связана 
с абстракциями данной группы, нежели с другими абстракциями за предела¬ 
ми группы. 

Декомпозиция инструментального средства разработки конструкций 
геометрической оптики. На рис. 9-9 показан наш проект модульной архи¬ 
тектуры для инструментального средства разработки конструкций геометриче¬ 
ской оптики. Наше приложение подразделяется на главную программу 
(MOptics), ресурсный файл (Optics.r.) и шесть программных модулей. По¬ 
скольку мы ожидаем, что каждый из этих программных модулей будет 
большим, мы можем использовать директиву компилятора, чтобы заставить 
их код расположиться в отдельных сегментах памяти. Выделение сегментов 
памяти — это, по всей видимости, отдельный вопрос по отношению к воп¬ 
росу о выборе структуры классов и объектов, и если включить его в проект 
модульной архитектуры, это позволит правильно рассуждать об альтернатив¬ 
ных подходах к сегментации без воздействия на любую другую часть наше¬ 
го проекта. 

Различное расположение модулей в этой архитектуре вытекает из двух 
факторов. Первый — это прошлый опыт. Построив несколько дюжин прило¬ 
жений МасАрр, мы перебрали много различных модульных архитектур. Не¬ 
которые из них работали хорошо, некоторые — не очень, и модульная ар¬ 
хитектура, изображенная на рис. 9-9, воспроизводит нашу последнюю кано¬ 
ническую декомпозицию. Это пример повторного использования проекта. Ес¬ 
ли оглянуться назад, все, что сработало хорошо, — это результат следова¬ 
ния принципам тщательной и серьезной разработки. Из этого следует второй 
фактор: когда мы разлагаем систему на модули, мы применяем основной 
критерий — разделение на различные области. Абстракции должны быть по¬ 
мещены в отдельные модули, если они связаны не прочно. Более того, если 
какое-то проектное решение может измениться, лучше всего скрыть его, 
чтобы оградить другие абстракции от последствий каких-либо изменений. 

Итак, на нижнем уровне архитектуры расположен модуль 
UOpticsModels, который содержит все классы и объекты, связанные с наибо¬ 
лее существенными элементами оптического эксперимента. Этот программ¬ 
ный модуль инкапсулирует большую часть проблемно-зависимого поведения 
приложения; любой другой программный модуль в первую очередь связан с 
интерфейсом пользователя. Следующим в иерархии модулей является про¬ 
граммный модуль UOpticsDialogs, который содержит все средства, необходи¬ 
мые для представления диалогов для взаимодействия с пользователями. 
UOpticsControllers построен над двумя программными модулями — 
UOpticsDialogs и UOpticsModels, и в этом программном модуле заключены 
все классы и объекты, относящиеся к командам пользователя. Далее следу¬ 
ют программные модули UOpticsViews, UOpticsDocuments и UOptics. Мы не 
объединяем эти программные модули, поскольку они содержат три различ¬ 
ных механизма. 

Для простоты на рис. 9-9 не изображены программные модули МасАрр; 
это сделало бы диаграмму излишне сложной, и, кроме того, диаграмма 
предназначена прежде всего для того, чтобы продемонстрировать проблемно¬ 
зависимую модульную архитектуру системы. Наша концепция состоит в том, 
что все классы и объекты МасАрр являются примитивными абстракциями, 
видимыми в любой части приложения. 
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Рис. 9-10. Диаграмма объектов оптического эксперимента. 

Отметим также, что мы решили сделать каждый программный модуль 
более низкого уровня видимым для интерфейса программного модуля следу¬ 
ющего, более высокого уровня. Итак, UOpticsDialogs должен использовать 
UOpticsModels, UOpticsControllers должен использовать UOpticsDialogs и 
UOpticsModels и т.д. В конце концов основная программа MOptics должна 
использовать все шесть программных модулей более низкого уровня. Мы 
могли бы уменьшить эти зависимости (хотя и не очень сильно), так как 
интерфейс каждого программного модуля более высокого уровня должен ви¬ 
деть почти каждый программный модуль под собой. Мы решили не оптими¬ 
зировать эти зависимости, потому что это сделало бы реализацию менее 
пригодной для понимания, так как ее модульная архитектура стала бы не¬ 
правильной. В любом случае устранение одной или двух сторонних зависи¬ 
мостей не окажет сильного влияния на время перекомпиляции. Фактически 
в ходе создания нашей реализации интерфейс каждого программного модуля 
оставался относительно стабильным, и большая часть изменений происходила 
в реализации программного модуля. Таким образом, это уменьшало пере¬ 
компиляцию благодаря устранению старых программных модулей. 

Почему же мы создали модульную архитектуру нашего приложения до 
разработки структуры его классов и объектов? На практике нам иногда ка¬ 
залось полезным сначала набросать в черновом виде модульную архитекту¬ 
ру, потому что это давало нам основную конструкцию, в рамках которой 
следовало постепенно разрабатывать наши проблемно-зависимые классы и 
объекты. Для небольших и средних по размеру систем, таких, как инстру¬ 
ментальное средство разработки конструкций геометрической оптики, проек¬ 
тирование с программными модулями или пакетами обеспечивает 
приемлемую основную конструкцию. Для больших систем, таких, как систе¬ 
ма, описанная в гл. 12, мы должны проектировать еще и с подсистемами 
более высокого уровня. Б каждом случае эти модули ({юрмируют программ¬ 
ные нодули для управления конфигурацией и для контроля версий, а также 
устанавливают пределы, в которых мы задаем работу разработчикам. 

Основной довод, который склоняет к тому, чтобы в первую очередь 
разрабатывать модульную архитектуру, состоит в том, что это способствует 
ранней и возрастающей интеграции. Итак, первое, что мы могли бы еде- 
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лать, создать эти программные модули (каждый из них первоначально пус¬ 
той) и затем компилировать, компоновать и выполнять результирующую пу¬ 
стую программу. Таким путем мы раньше начинаем применять наши инст¬ 
рументальные программные средства и обеспечиваем их соответствие данной 
архитектуре. Далее, по мере того как мы проектируем классы и объекты 
нашего приложения, мы можем сначала проверять их за пределами основ¬ 
ной конструкции, а затем добавлять их к основной конструкции, которая, 
как нам уже известно, стабильна и функциональна. Таким образом, каждая 
рабочая версия нашего приложения обрастает функционально во времени 
контролируемыми и предсказуемыми способами. 

Структура объектов 

В проекте системы домашнего отопления (гл. 12) все проблемно-зависи¬ 
мые объекты были статичны. Это типично лишь для некоторых проблемных 
областей, но, конечно, не характерно для подавляющего большинства про¬ 
блем автоматизации, с которыми мы встретимся. Например, проект инстру¬ 
ментального средства разработки конструкций геометрической оптики вклю¬ 
чает только один явно статичный объект — сам объект-приложение. В лю¬ 
бое время каждый объект-приложение может содержать ряд документов, 
каждый из которых представляет отдельный оптический эксперимент, а каж¬ 
дый оптический эксперимент может включать произвольное число линз. 
Кроме того, так как это приложение имеет однородный интерфейс, различ¬ 
ные объекты-команды, объекты отображения и диалоговые объекты могут 
быть созданы и уничтожены в цикле существования данного приложения. 
Так же как мы поступали при описании ключевого механизма МасАрр, мы 
можем использовать диаграммы объектов, чтобы представить ключевые меха¬ 
низмы среди транзитных объектов, которые формируют наш проект инстру¬ 
ментального средства разработки конструкций геометрической оптики. 

Из требований мы знаем, что оптический эксперимент состоит из набо¬ 
ра линз, расположенных вдоль оптической скамьи. Если мы проведем основ¬ 
ные лучи света от какого-либо реального объекта через этот набор линз, 
результирующий путь луча может сформировать изображения (и реальные, 
и мнимые). Это описывает состояние оптического эксперимента. Если обра¬ 
титься к терминам объектно-ориентированного программирования, свойства 
каждого оптического эксперимента включают набор линз, набор изображе¬ 
ний, набор лучей и один реальный объект, причем точные значения этих 
свойств могут изменяться со временем по мере того, как пользователь взаи¬ 
модействует с приложением — добавляет, удаляет и передвигает отдельные 
линзы. На рис. 9-10 на диаграмме объектов изображено данное проектное 
решение о структуре оптического эксперимента. 

Как показано на рис. 9-11, отдельные оптические эксперименты не су¬ 
ществуют изолированно, они взаимодействуют с. элементами ключевых меха¬ 
низмов МасАрр: с документами, объектами отображения и командами. Здесь 
мы видим, что документ состоит из оптйческого эксперимента и объекта 
отображения. Это — приложение механизма документов МасАрр. Используя 
механизм изображения МасАрр, объект отображения и оптический экспери¬ 
мент действуют вместе для поддержания соответствия между видимым изо¬ 
бражением эксперимента и текущим состоянием эксперимента. Используя 
механизм команд в МасАрр, объект отображения также может создать ко¬ 
манды-посредники, которые различными способами изменяют состояние экс¬ 
перимента. 
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Рис. 9-11. Диаграмма объектов инструментального средства 
разработки конструкций геометрической оптики. 

Запомним, что диаграмма объектов просто показывает прототипы дейст¬ 
вий. Следовательно, независимо от того, содержит ли данный оптический 
эксперимент одну линзу или сто линз, а текущий объект-команда представ¬ 
ляет перемещение, выбор картинки сервисной программы, удаление, копиро¬ 
вание, чистку или вставку, применяются такие же связи и взаимодействия, 
как изображенные на рис. 9-11. 

Структура классов 

Определение ключевых абстракций. В ходе проектирования инструмен¬ 
тального средства разработки конструкций геометрической оптики мы обна¬ 
руживаем ряд новых объектов, имеющих сходные свойства, но все же непо¬ 
хожих друг на друга. Например, в требованиях упомянуты три типа рассеи¬ 
вающих линз и три типа собирающих линз. Эти шесть объектов, несомнен¬ 
но, являются линзами, но они имеют различия в форме, а рассеивающие и 
собирающие линзы отличаются способом преломления лучей. Поскольку мы 
Можем выделить группы объектов определенного вида, подобно этим, 
следовательно между абстракциями, существующими в нашей проблемной 
области, следует установить отношения наследования. Если этого не сделать, 
наш проект будет намного хуже: в конце концов мы напишем больше ис¬ 
ходных текстов, так как не выделили общие черты абстракций, и, кроме 
того, наш проект трудно будет расширять и поддерживать. Здесь мы имеем 
дело с системой, отличной от домашнего отопления, в которой вопросы на¬ 
следования не выдвигались на первый план. 
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Большая часть структуры классов в оптическом эксперименте определя¬ 
ется интуитивно: есть класс TLens и оба класса TConvergingLens и 
Т DivergingLens наследуют от этого базового класса. Кроме того, имеются 
еще классы, представляющие типы собирающих линз, и, следовательно, они 
наследуют от класса TConvergingLens: 

* TDoubleConvexLens 

* TPlanoConvexLens 

* TConvexMeniscusLens 

Следующие классы представляют типы рассеивающих линз и, следова¬ 
тельно, наследуют от класса TDivergingLens: 

* TDoubleConcaveLens 

* TPlanoConcaveLens 

* TConcaveMeniscusLens 

Изображения (реальные и мнимые) и реальные объекты также связаны 
между собой. В оптическом эксперименте есть оба типа объектов, но един¬ 
ственный реальный объект статичен в данном эксперименте, а все остальные 
объекты, как предполагается, динамические. Поскольку в нашем представле¬ 
нии о мире достаточно много различных понятий, мы решили ввести два 
класса TRealOrVirtuallmage и TRealObject, которым присуще одинаковое по¬ 
ведение как подклассам класса TImage. 

Достаточно ли существенны различия между реальными и мнимыми 
изображениями, чтобы служить основанием для ввода двух отдельных клас¬ 
сов? В соответствии с требованиями единственное различие между этими 
двумя типами объектов состоит в том, что реальные изображения должны 
быть выполнены в темно-сером цвете, а мнимые — в светло-сером. Рассуж¬ 
дая таким образом, введение этих двух классов можно было бы считать оп¬ 
равданным. Однако то, что изображение является реальным или мнимым, 
зависит всего лишь от того, с какой стороны линзы появляется это изобра¬ 
жение по отношению к первоначальному изображению. 

Итак, мы могли бы использовать состояние, внутреннее для изображе¬ 
ния (расположение изображение по отношению к линзе), для того, чтобы 
решить в каком цвете — темно- или светло-сером представить его на экра¬ 
не. В данном случае одного класса было бы не вполне достаточно. Какой 
же проект лучше? Мы считаем, что оба имеют свои достоинства. Тем не 
менее, поскольку мы не можем найти достаточно веских причин для созда¬ 
ния двух классов, у нас остается один лишь класс TRealOrVirtuallmage. 

Следует обратить внимание еще на некоторые общие моменты. Есть ли 
какое-либо сходство между линзами и изображениями? Да, есть: и линзы, и 
изображения могут быть изображены на экране в объекте отображения, сле¬ 
довательно, есть поля и операции, являющиеся общими для этих двух боль¬ 
ших классов объектов. Исходя из этого, мы можем ввести класс TShape, 
который будет суперклассом по отношению к обоим классам TLens и 
TImage. В наших требованиях речь идет о лучах света, и поэтому мы мо¬ 
жем ввести класс TRays, который отражает поведение, общее для всех лу¬ 
чей. Так как лучи, подобно линзам и изображениям, могут быть изображе¬ 
ны на экране в объекте отображения, мы также можем сделать класс TRays 
подклассом класса TShape. Как мы говорили в гл. 3, если объект состоит из 
других объектов, то его класс должен использовать классы его компонентов. 
Это относится к классу TOpticsModel, который инкапсулирует состояния, об¬ 
щие для всех оптических экспериментов, и поэтому использует классы 
TLens, TImage и TRays. 
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Оптическая скамья тоже считается объектом, так как является четко 
определенной абстракцией. Хотя она не участвует в прохождении лучей, 
она является действительной и в соответствии с требованиями по команде 
пользователя может быть . видимой или невидимой. Поэтому мы вводим 
класс TOpticsBench как атрибуѵ объекта отображения, который изображает 
на экране оптический эксперимент. На рис. 9-12 изображены почти все вве¬ 
денные нами классы. Для простоты мы не стали включать в схему исполь¬ 
зуемые отношения для класса TOpticsModel. Отметим, что мы представили 
несколько классов (таких, как TLens) в виде абстрактных классов, так как 
они являются обобщенными классами, которые требуют дальнейшей специа¬ 
лизации, прежде чем могут быть созданы какие-либо экземпляры этих 
классов. 

Нужно также сказать, что мы представили данную часть проекта в бо¬ 
лее простом виде, чем это есть в действительности. На рис. 9-12 проект 
классов представлен в своем окончательном варианте, но не в процессе сво¬ 
его развития. Сначала мы спроектировали шесть типов линз в качестве не¬ 
посредственных подклассов класса TLens. В ходе проектирования каждого 
класса мы пришли к тому, что этот процесс можно представить в виде не¬ 
которой схемы. Три собирающие и три рассеивающие линзы обнаружили до¬ 
статочно сходства в своем представлении и поведении, и поэтому мы ввели 
два промежуточных класса TConvergingClassLens и TDivergingLens, которые 
отражают сходные представление и поведение каждого типа линз. В 
результате это упростило проектирование каждого из наиболее специализи¬ 
рованных классов. Поскольку некое общее понятие объединяет линзы, реаль¬ 
ный объект, лучи и изображения, мы ввели класс TShape. Тем самым мы 
наделили этот более абстрактный класс общим для данных подклассов пред¬ 
ставлением и поведением, и это снова позволило нам уменьшить объем ис¬ 
ходных текстов. 

Данный тип реорганизации классов довольно широко используется в 
процессе разработки. Конечно, мы не можем поступать так постоянно, пото¬ 
му что нам все время приходилось бы производить изменения в интерфейсе 
и большую часть времени заниматься перекомпиляцией программных моду¬ 
лей. Если дана большая система, каждому разработчику пришлось бы ждать, 
пока работа других разработчиков не стабилизируется, и в конечном счете 
замедлилась бы вся работа над проектом. Хотя на практике структура клас¬ 
сов в системе некоторое время действительно остается неустойчивой, но по 
мере того как разрабатываются ключевые решения об архитектуре модулей, 
она стабилизируется. После этой стадии, на которой разработчики обычно 
приступают к написанию исходных текстов для интерфейсов и, следователь¬ 
но, стабильность становится для них необходимым условием, единственные 
изменения, которые вносятся в структуру классов, это введение новых под¬ 
классов или добавление операций к интерфейсам существующих классов. 
Именно так мы поступали в проекте инструментального средства разработки 
конструкций геометрической оптики. Мы пришли к выводу, что следует 
планировать внесение изменений, потому что избежать их невозможно. Если 
на начальной стадии разработки проекта не вносить в него изменения, вряд 
ли можно будет быстро сделать его оптимальным. Может наступить момент, 
когда проявятся последствия плохого проектирования на начальном этапе, и 
вы не сможете двигаться дальше, и у вас не будет иного выбора, кроме 
как исправлять свои ошибки в проекте. Это потребует значительно большего 
времени, чем если бы вы решили эту проблему раньше. 
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Рис. 9-12. Диаграмма классов оптического эксперимента. 

Теперь мы можем приступить к проектированию интерфейса каждого из 
наших классов. Мы могли бы написать шаблоны для каждого класса, но по¬ 
скольку Object Pascal — весьма выразительный язык, лучше написать их 
непосредственно на языке реализации. Однако следует быть осторожным и 
избегать непродуманных решений о представлении классов. Как мы говорили 
выше, представление класса должно обычно вытекать из его ожидаемого по¬ 
ведения. Итак, мы можем регулировать представление классов, чтобы сде¬ 
лать его оптимальным с учетом использования классов в будущем, причем 
поступать иначе крайне нежелательно, так как объекты-пользователи начи¬ 
нают зависеть от непродуманного представления классов, которое в процессе 
работы может измениться. 

Проект оптической модели. Класс TShape представляет общее для всех 
классов поведение, которое может быть изображено в объекте отображения. 
Это означает, что он должен включать знания о механизме изображения в 
МасАрр и знать такое понятие, как отмена объекта отображения. Мы могли 
бы начать создавать интерфейс к этому классу следующим образом: 

TShape - objecl(TObject) 

procedure TShape.IShape (AnOpticsModel : TOpticsModel); 

procedure TShape.Invalidate; 

function TShape.Frame : Reel; 


Многоточие показывает, где мы должны в конечном счете объявить по¬ 
ля этого класса, которые мы учитываем, так как это предусмотрено реали¬ 
зацией. 
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Заметим, что мы объявили метод IShape, который, как принято, мы 
должны вызвать сразу же после создания нового объекта класса. Обычно мы 
производим эти операции в Object Pascal, так как ц отличие от C++, Object 
Pascal не позволяет нам объявлять операции конструктор или деструктор, а 
также потому, что Object Pascal в отличие от Smalltalk не поддерживает 
метаклассы. Мы также объявили процедуру Invalidate для поддержки меха¬ 
низма изображения в .МасАрр. Эта процедура использует общедоступную 
функцию Frame, возвращающую прямоугольник, в который заключен объект. 
Мы указали на эту функцию, потому что вскоре мы обратимся к ней для 
поддержки механизма действия мыши в МасАрр. 

Мы не экспортировали никаких методов, реализующих изображение, по¬ 
тому что, как мы увидим ниже, каждый из подклассов класса TShape, тре¬ 
бует набора параметров, несколько отличающегося от набора параметров его 
собственного метода Draw. Поскольку для Object Pascal нежелательно слиш¬ 
ком большое количество имен методов, мы не можем объявить эти различ¬ 
ные методы, реализующие изображение, в одном месте. 

Класс TLens немного сложнее, потому что он должен отразить поведе¬ 
ние, общее для всех линз. Его интерфейс выглядит следующим образом: 

TLens - object (TShape) 

procedure TLens.IShape (AnOpticsModel : TOpticsModel); override; 

procedure TLens.SetFocallength (NewFocalLength : Focal Length); 

procedure TLens.Select; 

procedure TLens.Deselect; 

procedure TLens.Invalidate; override; 

procedure TLens.Highlight (FromHL, ToHL : HLState); 

procedure TLens.DrawLens (DrawPosition: Boolean); 

procedure TLens.Draw (Area : Reel; DrawPosition : Boolean); 

procedure TLens.DoRead (ARefNum : Integer); 

procedure TLens.DoWrite (ARefNum : Integer); 

function Thlens.DiskSpace : Longlnt; 
function TLens.Frame : Rect; override; 


Этот класс экспортирует процедуру IShape, которая замещает соответст¬ 
вующую процедуру класса TShape. Процедура SetFocalLength предназначена 
для установки фокусного расстояния. Но почему бы нам просто не объявить 
некоторое поле fFocalLength, к которому объект-пользователь может полу¬ 
чить непосредственный доступ? Это привело бы нас к объектам-пользовате- 
лям, находящимся в зависимости именно от данной конкретной реализации 
этого класса, но не от его абстрактных свойств. Изменение фокусного рас¬ 
стояния линзы имеет побочный эффект, кроме того, что просто дает новое 
значение некоторому полю: изменение фокусного расстояния линзы позволя¬ 
ет заново рассчитывать пути лучей. Обращение к этому методу дает новую 
оптическую модель, если для линзы задается новое фокусное расстояние. 

Процедуры Select и Deselect представляют примитивные операции над 
всеми линзами, они необходимы для поддержки механизма действия мыши в 
МасАрр. Например, пользователь может нажатием на клавишу мыши опери¬ 
ровать линзой, изображенной в объекте отображения; при этом сразу же 
вызывается метод Select для выбора этой линзы. Методы Invalidate, 
Highlight, DrawLens и Draw предназначены для поддержки механизма изо- 
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бражения в МасАрр. Мы представляем метод DrawLens, являющийся прими¬ 
тивной операцией, которая всегда изображает линзу (и ее положение на оп¬ 
тической скамье, если оптическая скамья видима) и составную операцию 
Draw, которая вызывает метод DrawLens при условии, что рамка линзы по¬ 
падает в отменяемую часть объекта отображения. 

Методы DoRead, DoWrite и DiskSpace предназначены для поддержки ме¬ 
ханизма документов в МасАрр. DiskSpace определяет объем памяти, необхо¬ 
димый для сохранения состояния объекта, a DoRead и DoWrite выполняют 
работу по восстановлению и сохранению состояния. 

Интерфейсы к классам TConvergingLens и TDivergingLens — довольно 
простые. В каждом из них мы должны заменить метод IShape так, чтобы 
состояние каждого типа объектов устанавливалось соответствующим образом. 
Итак, мы могли бы записать: 

TConvergingLens - object (TLens) 

procedure TConvergingLens.IShape (AnOpticsModel : TOpticsModel); override; 




Аналогично интерфейс каждого из шести наиболее специализированных 
классов линз должен всего лишь заменить метод IShape своего суперкласса. 
Например, мы могли бы записать интерфейс к классу TDoubleConvexLens 
следующим образом. 

TDoubleConvexLens - object(TConvergingLens) 

procedure TDoubleConvexLens.IShape (AnOpticsModel : TOpticsModel); override; 


Может показаться странным, что у нас так много небольших классов, 
таких как TConvergingLens и TDoubleConvexLens. Следует еще раз повто¬ 
рить наши соображения по этому поводу: построение простых классов, 
включающих только конкретное поведение, имеет очень большое значение. 
Общее поведение может перейти к обобщенным классам, а это означает, 
что придется записывать и поддерживать меньше исходных текстов, что 
приводит к большей открытости системы и упрощает ее обслуживание. Кро¬ 
ме того, очень важно, что мы стараемся вводить классы, использующие тер¬ 
минологию, принятую в данной проблемной области, чтобы получить прило¬ 
жение, доступное для понимания. Введение классов, подобных 
TConvergingLens и TDoubleConvexLens, — важный этап в решении пробле¬ 
мы: создавая их, мы отражаем наше действительное представление о внеш¬ 
нем мире. 

Рассмотрим класс TRays. Экземпляр данного класса представляет все 
основные лучи, проходящие через отдельную линзу. Достаточно ли прост 
этот класс? Почему вместо него мы не ввели класс TPrincipleRays, имею¬ 
щий подклассы для каждого из трех основных лучей? Мы могли бы так 
сделать, но это усложнило бы проблему, по крайней мере в данном конк¬ 
ретном случае. Как мы выяснили, основные лучи, проходящие через отдель¬ 
ную линзу, внутренне взаимосвязаны: они исходят от одного и того же ре¬ 
ального объекта, реального или мнимого изображения, и все они сходятся 
на одном и том же реальном или мнимом изображении. Более того, когда 
19 Гради Буч 
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мы вычислим точку, в которой сходятся два из этих трех лучей, мы можем 
легко определить путь третьего луча. Если бы мы рассматривали эти три 
луча по отдельности, обработка заняла бы у нас на треть больше времени, 
чем необходимо. Поэтому мы решили определить класс TRays как класс, 
включающий поведение всех трех основных лучей, проходящих через линзу. 

Этот класс требует интерфейс, аналогичный интерфейсу класса TLens: 
требуются такие операции, как IShape, DrawRays, Draw и Frame для под¬ 
держки механизма изображения в МасАрр. Поскольку семантика класса 
TRays представляет три основных луча, мы должны ввести метод, который 
устанавливает состояние объектов-лучей, так чтобы DrawRays и Draw могли 
нормально работать. Согласно требованиям, главный луч изображается про¬ 
ходящим от реального объекта (или реального либо мнимого изображения) 
через линзу. Луч, идущий от линзы, может быть затем проведен в обрат¬ 
ном направлении — либо к реальному объекту (если он фокусируется на 
противоположной от первоначального изображения стороне линзы) или к 
мнимому изображению (если он фокусируется на той же стороне линзы, где 
находится первоначальное изображение). Итак, отдельный луч может быть 
определен двумя расположенными рядом отрезками, конечные точки которых 
находятся на первоначальном изображении, где-то на прямой, перпендику¬ 
лярной оптической оси и на полученном реальном или мнимом изображе¬ 
нии. Следовательно, все три основных луча пересекутся в полученном ре¬ 
альном или мнимом изображении при условии, что они фокусируются в 
точке, отличной от бесконечности, и мы исключаем помехи, вызванные сфе¬ 
рической аберрацией. 

Если даны только реальный объект или реальное либо мнимое изобра¬ 
жение и линза, через которую проходит луч, то можно определить прими¬ 
тивную операцию для класса TRays, которая вычисляет точку, где пересека¬ 
ются основные лучи. Полученная точка вместе с первоначальным изображе¬ 
нием и линзой — достаточное условие, чтобы правильно изобразить все три 
основных луча. Поэтому мы будем экспортировать метод SetPoint, который 
выполняет это действие, несмотря на то что мы можем установить, как ра¬ 
ботает SetPoint. Как показано ниже, мы должны вернуться к методам 
структурного проектирования для дальнейшей декомпозиции этого метода, и, 
поступая таким образом, мы находим дополнительные классы, имеющие 
прямое отношение к нашему проекту. 

Если принять эти проектные решения, можно записать интерфейс к 
классу TRays следующим образом: 

TRays - object(TShape) 

procedure TRays.IShape (AnOpticsModel : TOpticsModel); override; 
procedure TRays.SelPoint (Fromlmage : TImage; ThroughLens : TLens); 
procedure TRays.DrawRays; 
procedure TRays.Draw (Area : Rect); 

function TRays.Frame : Reel; override; 
function TRays.ImageAt : Point; 




Как всегда в таких случаях, когда бы мы ни определяли модификатор, 
такой, как SetPoint, мы также определяем селектор, такой, как ImageAt, 
который возвращает состояние, связанное с модификатором. 
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Интерфейс класса TImage во многом напоминает интерфейс класса 
TLens. Цель класса TImage — включить поведение, общее для всех реаль¬ 
ных объектов и реальных или мнимых изображений. Итак, мы могли бы 
записать интерфейс класса TImage следующим образом: 

TImage - object(TShape) 

procedure TImage.IShape (AnOpticsModel : TOpticsModel); override; 
procedure TImage.DrawImage; 
procedure TImage.Draw (Area : Reel); 

function TImage.Frame : Rect; override; 




Два подкласса класса TImage большей частью переопределяют эти опе¬ 
рации. Итак, мы могли бы записать: 

TRealObJect - object(TImage) 

procedure TRealObject.DrawImage; override; 
procedure TRealObject.Draw (Area : Rect); override; 


TRealOrVirtuallmage - object (TImage) 

procedure TReallmage.SetPosition (TheTop : Point; FromLens : TLens); 
procedure TReallmage.DrawImage; override; 
procedure TReallmage.Draw (Area : Rect); override; 


Класс TRealOrVirtuallmage экспортирует метод SetPosition, целью кото¬ 
рого является обнаружение местоположения изображения, относящегося к 
данной линзе. Если оно расположено с той же стороны линзы, что и реаль¬ 
ный объект, это изображение будет мнимым. Если оно расположено на про¬ 
тивоположной стороне, то это будет реальное изображение. Метод SetPosition 
определен именно здесь, так как он может быть реализован только при ус¬ 
ловии, что мы имеем доступ к глубинному представлению класса. 

Чтобы завершить наше проектирование ключевых классов, участвующих 
в оптических экспериментах, мы должны определить интерфейс класса 
TOpticsModel, который инкапсулирует все объекты, относящиеся к экспери¬ 
менту. Как и для класса TLens, мы должны обеспечить операции, которые 
поддерживают механизмы документов, изображения и действия мыши в 
МасАрр. Итак, мы должны обратиться к таким методам, как IOpticsModel, 
Select All, Draw, DoRead и DiskSpace. 

Для определения остальных операций, которые данный класс должен 
экспортировать, нам следует подумать о том поведении, которое предполага¬ 
ем увидеть у всех объектов данного класса. Поскольку оптический экспери¬ 
мент включает набор линз, мы должны ввести такие модификаторы, как 
AddLens и RemoveLens, и такие селекторы, как NumberOfLenses, и такие 
иттераторы, как EachLens. Нужно ли нам также обращаться к операциям, 
позволяющим обьекту-пользователю манипулировать лучами и изображения¬ 
ми в ходе эксперимента? Наш ответ на этот вопрос — нет. Объект-пользо- 
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ватель не сможет разумно обращаться с этими объектами, и поэтому мы 
решили поместить лучи и изображения в ту часть оптического эксперимен¬ 
та, которая относится к реализации. 

Тем не менее оптический эксперимент содержит достаточно знаний и 
условий, чтобы рассчитать пути лучей, и поэтому мы решили экспортиро¬ 
вать метод TraceRays. Этот метод является основным для всех проблемно¬ 
зависимых алгоритмических транзакций внутри самого приложения. Несмот¬ 
ря на важность этого метода, нам не стоит думать о том, как реализовать 
его, ибо его реализация связана с вопросами очень низкого уровня абстрак¬ 
ций. К счастью, как мы увидим ниже, реализация этого метода довольно 
проста, так как использует уже разработанные нами для класса TLens и его 
подклассов подробные интерфейсы. 

Соединив эти проектные решения, мы теперь можем записать интер¬ 
фейс класса TOpticsModel: 

TOpticsModel - object(TObject) 

procedure TOpticsModel.IOpticsModel; 

procedure TOpticsModel.Free; override; 

procedure TOpticsModel.TraceRays; 

procedure TOpticsModel.AddLens (ALens ; TLens); 

procedure TOpticsModel.RemoveLens (ALens: TLens); 

procedure TOpticsModel.SelectAli; 

procedure TOpticsModel.DeselectAll; 

procedure TOpticsModel.Highlight (FromHL, ToHL : HLState); 
procedure TOpticsModel.Draw (Area : Rect; DrawPosition : Boolean); 
procedure TOpticsModel.DoRead (ARefNum : Integer); 
procedure TOpticsModei.DoWrite (ARefNum : Integer); 

function TOpticsModei.DiskSpace : Longlnt; 
function TOpticsModel.CurrentSize : Point; 
function TOpticsModel.NumberOfLenses : Integer; 
function TOpticsModel.NumberOfSelections : Integer; 

procedure TOpticsModel.EachLens (procedure DoToLens (ALens : TLens)); 
function TOpticsModel.FirstLensThat (function TestLens 

(Aiens : TLens) : Boolean) : TLens; 


Как мы обычно поступаем в таких случаях, для удобства пользователя 
мы подразделили операции на модификаторы, селекторы и иттераторы. 

Как только мы определили интерфейс класса TOpticsModel, мы можем 
подумать о представлении этого класса. Здесь очевидны две реализации: 1) 
использование единого гетерогенного списка линз, изображений и лучей, 2) 
использование различных списков. Мы убеждены, что использование гетеро¬ 
генного списка приводит к более сложной и менее эффективной реализации 
некоторых методов. Например, удаление линзы в таком случае потребовало 
бы обхода по списку объектов, многие из которых заведомо не являются 
линзами. Кроме того, расчет пути луча в первую очередь предусматривает 
устранение всех имеющихся изображений и лучей, и затем — создание но¬ 
вых, но при устранении старых изображений и лучей возникает та же про¬ 
блема, что и при удаление линз из гетерогенного списка. Поэтому мы счи¬ 
таем, что состояние оптического эксперимента — это объединение гомоген¬ 
ных объектов. Итак, мы могли бы записать его поля следующим образом: 
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Модель должна знать объект отображения, в котором она появляется 
(чтобы она могла устранять линзы, изображения и лучи по мере их изме¬ 
нения), и таким образом мы обращаемся к полю fView. 

Независимо от представления классов мы должны думать о чистке па¬ 
мяти, потому что эксперимент находится в динамическом состоянии, следо¬ 
вательно, мы экспортируем метод Free. Почему мы не экспортируем метод 
Free в каком-либо другом классе? Дело в том, что состояния объектов в 
классе TOpticsModel и состояния объектов в любом другом подклассе класса 
TShape существенно различаются. Объекты класса TOpticsModel инкапсули¬ 
руют другие объекты, такие, как линзы, и поэтому, коща мы завершаем 
работу с отдельной оптической моделью (например, когда мы закрываем до¬ 
кумент), мы должны также освободить подобьекты. С другой стороны, состо¬ 
яние таких объектов, как объекты класса TLens, весьма простое (оно состо¬ 
ит главным образом из скалярных величин), следовательно, они не содержат 
другие объекты, которые нужно высвобождать. 

На этом мы завершаем наше проектирование ключевых классов, свя¬ 
занных с оптическим экспериментом. В соответствии с нашей модульной ар¬ 
хитектурой системы каждый из рассмотренных нами классов описан в ин¬ 
терфейсе программного модуля UOpticsModels. 

Проектирование классов интерфейса пользователя. В проектировании 
классов, составляющих интерфейс пользователя данного приложения, широко 
используется наследование для специализации существующих в МасАрр 
классов. Их интерфейсы включают мало новых операций, наоборот, они в 
основном переопределяют операции, определенные в своих суперклассах. 
Программисту, впервые столкнувшемуся с МасАрр, приходится методом проб 
и ошибок догадываться, какие операции отменять, но для разработчика, хо¬ 
рошо знакомого с механизмом МасАрр, это не составляет никакого труда. 

На рис. 9-13 представлена структура классов приложения, документов и 
объектов отображения инструментального средства разработки конструкций 
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геометрической оптики. Так как встроенные в МасАрр классы TApplication, 
TDocument и TView важны для этого проекта, мы включили их в эту диаг¬ 
рамму. Их имена подчеркнуты для того, чтобы отметить, что они взяты из¬ 
вне (не из нашего приложения). 

Как показано на диаграмме, мы ввели классы TOpticsApplication и 
TOpticsDocument, которые соответственно наследуют от встроенных классов 
TApplication и TDocument. Аналогично мы создали классы TOpticsView и 
TPaletteView как подклассы класса TView. Оставшийся класс 
TOpticsDocimentManager введен в соответствии с данными требованиями: на¬ 
ше приложение должно поддерживать не более четырех документов одновре¬ 
менно. Поскольку обработка, необходимая для перехода от одного экспери¬ 
мента к другому, логически автономна, хотя чем-то и отличается от обыч¬ 
ной обработки документов, имеющейся в МасАрр, мы решили определить 
класс, отвечающий за обеспечение данного поведения. Включение знаний об 
управлении составными документами в отдельный класс упрощает структуру 
подкласса TOpticsApplication. Другой убедительный довод в пользу введения 
данного класса — это то, что требование обрабатывать не более четырех 
документов одновременно возможно может измениться. Экземпляры класса 
TOpticsDocumentManager должны отслеживать четыре различных документа. 
Со стороны мы видим, что данный класс должен знать, как добавить новый 
документ в приложение (когда пользователь выбирает New или Open в File - 
меню), как удалить документ из приложения (когда пользователь выбирает 
Close в File -меню) и как переименовать документ (когда пользователь выби¬ 
рает Save As в File меню). Кроме того, данный класс должен знать, как 
активизировать окно, связанное с документом, когда пользователь выбирает 
имя данного документа из соответствующего меню. Эти четыре модификато¬ 
ра являются примитивными операциями, так как мы можем реализовать их 
только при условии, что мы имеем доступ к глубинной реализации класса, 
поэтому их следует включить в интерфейс TOpticsDocumentManager. С по¬ 
мощью селекторов данный класс содержит достаточно сведений, чтобы знать, 
можно ли открыть еще документы, помимо имеющихся, и вообще имеются 
ли открытые документы. 

Теперь мы можем записать интерфейс класса TOpticsDocumentManager 
следующим образом: 

TOpticsDocumentManager - object(TObject) 

procedure TOpticsDocumentManager.IOpticsDocumentManager; 
procedure TOplicsDocumentManager.DoSetUpMenus; 

procedure TOpticsDocumentManager.AddDocument (ADocument : TOpticsDocument); 
procedure TOpticsDocumentManager.DeleteDocument (ADocument : TOpticsDocument); 
procedure TOpticsDocumentManager.RenameDocument (ADocument : TOpticsDocument); 
procedure TOpticsDocumentManager.FocusOnADocument (ACmdNumber : CmdNumber); 

function TOpticsDocumentManager.CanAddDocument : Boolean; 
function TOpticsDocumentManager.HasOpenDocuments ; Boolean; 




Данный класс также экспортирует метод IOpticsDocumentManager для 
инициализации объектов и метод DoSetUpMenus, который необходим нам 
для поддержки механизма команд меню в МасАрр. 

Класс TOpticsApplication в основном просто переопределяет некоторые 
операции своего базового класса TApplication для поддержки проблемно-зави- 
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симой обработки меню и документов. Поскольку мы хотим, чтобы данный 
класс использовал средства объекта управления документами, который мы 
только что спроектировали, мы должны включить в класс TOpticsApplication 
поле, которое содержит объект класса TOpticsDocumentManager. Это поле 
представляет проблемно-зависимое состояние, и, следовательно, мы должны 
также включить в этот класс соответствующую инициализацию и методы 
чистки памяти. Итак, мы можем записать интерфейс класса 
TOpticsApplication следующим образом: 

TOpticsApplication - object(TApplication) 

fOpticsDocumentManager : TOpticsDocumentManager; 

procedure TOpticsAppiication.IOpticsApplication; 
procedure TOpticsApplication.Free; override; 
procedure TOpticsApplication.DoSetUpMenus; override; 

procedure TOplicsApplication.AddDocument (ANewDocument : TDocument); override; 
procedure TOpticsApplication.DeleteDocument (DocToDeiete : TDocument); override; 

function TOpticsApplication.DoMenuCommand 

(ACmdNumber : CmdNumber) : TCommand; override; 
function TOpticsApplication.DoMakeDocument 

(ItsCmdNumber : CmdNumber) : TDocument; override; 
function TOpticsApplication.MakeViewForAlienClipboard : TView; override; 


Метод MakeViewForAlienClipboard предназначен для поддержки буфера 
Macintosh. Когда начинается работа с новым приложением, моіуг иметься 
объекты (оставшиеся из буфера другого приложения), которые обрабатывало 
инструментальное программное средство разработки конструкций геометриче¬ 
ской оптики. Данный метод проверяет наличие таких объектов и создает бу¬ 
фер для хранения любых найденных объектов. 

Два класса TOpticsDocumentManager и TOpticsApplication объявлены в 
программном модуле UOptics согласно с ранее введенной модульной архитек¬ 
турой. 

Проект класса TOpticsDocument во многом аналогичен проекту класса 
TOpticsApplication. Его целью является переопределение методов суперкласса 
для того, чтобы поддержать проблемно-зависимую обработку МасАрр команд 
меню и механизмов документов. Таким образом, мы можем написать интер¬ 
фейс класса TOpticsDocument следующим образом: 

TOpticsDocument - object (TDocument) 

procedure TOpticsDocument.IOpticsDocument; 

procedure TOpticsDocument.Free; override; 

procedure TOpticsDocument.DoMakeWindows; override; 

procedure TOpticsDocument.DoMakeViews (ForPrinting : Boolean); override; 

procedure TOpticsDocument.DoNeeDiskSpace (var DataForkBytes. 

RsrcForkBytes : Longlnt); override; 
procedure TOpticsDocument.DoRead (ARefNum : Integer; 

RsrcExists, 

ForPrinting : Boolean); override; 
procedure TOpticsDocument.DoWrite (ARefNum : Integer; 

MakingCopy : Boolean); override; 
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Данный класс объявлен в интерфейсе программного модуля 
U OpticsDocuments . 

Рассмотрим более подробно классы TOpticsView и TPaletteView. Объекты 
этих двух классов совместно реализуют окно палитры подобно тому, как 
показано на рис. 9-3. Экземпляры класса TOpticsView выводят на экран 
изображения элементов данного оптического эксперимента, тогда как эк¬ 
земпляры класса TPaletteView обеспечивают выбор сервисной программы, 
которую пользователь может применить для создания или модификации оп¬ 
тического эксперимента в соответствующем оптическом объекте отображения. 

Большей частью интерфейс класса TOpticsView представляет собой про¬ 
сто переопределенные операции его суперкласса TView, для того чтобы под¬ 
держать механизмы изображения и команд меню МасАрр. Поэтому мы дол¬ 
жны заменить методы CalcMinSize (для поддержки объектов отображения с 
переменными размерами), DoHighlightSelections, Draw, DoSetUpMenus, 
DoMouseCommand, DoMenuCommand и DoSetCursor. 

В соответствии с требованиями устанавливаем, что оптические объекты 
отображения могут содержать несколько визуальных атрибутов, включая 
метки шкалы, разделители страниц и оптическую скамью, и каждый из них 
может быть или не быть видимым согласно желанию пользователя. Эти ат¬ 
рибуты отражают сущность данной проблемной области, и поэтому имеет 
смысл экспортировать такие операции, как ToggleDrawOpticalBench и 
ToggleDrawGridLines, которые обеспечивают данное поведение. Мы решили 
экспортировать скорее операции, которые переключают соответствующее 
Boolean состояние, а не устанавливать True- или False- состояние для каж¬ 
дого атрибута. Этим достигается лучшее согласование с механизмом команд 
меню МасАрр, в котором определенное меню просто переключается из одно¬ 
го состояния в другое. Тем не менее надо отдавать себе отчет в том, что 
эти операции не только устанавливают состояние некоторого булева поля. 
Изменение состояния одного из этих атрибутов также заставляет обновлять 
объект отображения. Должны ли мы также экспортировать операции селек¬ 
торы, которые восстанавливают состояние этих свойств? Теоретически да, но 
так как Object Pascal не инкапсулирует свои поля и данное состояние 
является примитивным, мы разрешили обьекту-пользователю прямой доступ 
к соответствующему состоянию. Это отличается от нашего проектного реше¬ 
ния для селекторов, определенных в классе TOpticsDocumentManager, потому 
что в последнем случае мы ожидаем, что каждое возвращаемое значение 
должно было бы скорее вычислено, чем взято непосредственно в поле. 

Что касается его представления, то каждый оптический объект отобра¬ 
жения должен быть видимым для модели, которую он изображает на экра¬ 
не, для согласования с механизмом изображения МасАрр. Поскольку мы 
имеем два раздельных класса TOpticsModel и TOpticalBench, то мы должны 
включить два поля, по одному для каждого объекта этих классов. Оптиче¬ 
ский объект отображения должен также быть видимым для его палитры, так 
как объект отображения знает, какую сервисную программу выбрал пользо¬ 
ватель. Таким образом, мы должны включить поле, которое содержит объ¬ 
ект-палитра. И наконец, мы должны включить булево поле для каждого ат¬ 
рибута, который может переключаться в объекте отображения. 

Исходя из этих проектных решений и решений реализации, мы можем 
написать интерфейс класса TOpticsView следующим образом: 
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TOpticsView - object (TView) 

fOpticsModel : TOpticsModel; 

fOpticalBenc : TOpticalBench; 

fPaletteView : TPaletteView; 

fDrawOpticalBench : Boolean; 

fDrawGridLines : Boolean; 

fDrawPageBreaks : Boolean; 

fAutoGridEnabled : Boolean; 

procedure TOpticsVIew.IOpticsView (ADocument ; TDocument; 

APalette : TPaletteView; 

AModel ; TOpticsModel); 

procedure TOpticsView.CalcMinSize (var MinSlze : VPoint); override; 
procedure TOpticsView.ToggleDrawOpticalBench; 
procedure TOpticsView.ToggleDrawGridLines; 
procedure TOpticsView.ToggleDrawPageBreaks; 
procedure TOpticsView.ToggleAutoGridEnabled; 

procedure TOpticsView.DoHighLightSeiection (FromHL, ToHL : HLState); override; 

procedure TOpticsView.DrawGridLine (Area ; Rect); 

procedure TOpticsView.Draw (Area : Rect); override; 

procedure TOpticsView.DoSetUpMenus; override; 

function TOpticsView.DoMouseCommand (var TheMouse : Point; 

var Info : Eventlnfo; 

var Hysteresis : Point) : TCommand; override; 

function TOpticsView.DoMouseCommand (ACmdNumber : CmdNumber) : TCommand; override; 
function TOpticsView.DoSetCursor (LocalPoint : Point; 

CursorRgn : RgnHandle) : Boolean; override; 

end; 

Объект класса TPaletteView представляет палитру сервисных программ, 
среди которых пользователь может сделать выбор. Для нашего приложения 
соответствующее инструментальное средство включает указатель (для выбора 
линз) и сервисную программу изображения для каждой из шести типов 
линз, которые мы должны моделировать. TPaletteView должен инкапсулиро¬ 
вать знания о том, как изображать данные сервисные программы, а также 
как реагировать на выбор новой сервисной программы пользователем. В на¬ 
шем проекте объект-палитра не знает, что делать с сервисной программой, 
а объект отображения знает. Поэтому наше проектное решение заключается 
в том, что, когда пользователь выбирает новую сервисную программу, объ¬ 
екту-палитре необходимо только отменить выбор старой сервисной програм¬ 
мы и выделить новую сервисную программу. Изображаемый объект отобра¬ 
жения, соответствующий данному объекту-палитре, может запросить объект- 
палитру о выбранной в настоящий момент сервисной программе (которая 
либо указатель, либо линза), когда это необходимо. Для поддержки этих 
решений мы должны ввести селекторы для класса TPaletteView, такие, как 
IsPointer (возвращающий True, если указательная сервисная программа вы¬ 
брана в данный момент и False в другом случае) и CurrentTool (который 
возвращает объект подкласса TLens, соответствующий выбранной в данный 
момент сервисной программе изображения линзы). Поэтому мы можем запи¬ 
сать интерфейс данного класса следующим образом: 

TPaletteView - object (TView) 

procedure TPaletteView.IPaletteView (Document : TDocument; 

AModel ; TOpticsModel); 

procedure TPaletteView.DoHighlighSelection (FromHL, ToHL : HLState); 

override; 

procedure TPaletteView.Draw (Area : Rect); override; 
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function TPaletteView.DoMouseCommand (var TheMouse : Point; 

var Info ; Eventlnfo; 
var Hysteresis : Point) : TCommand; 
override; 

function TPaletteView.IsPointer : Boolean; 
function TPaletteView.CurrentTool ; TLens; 

end; 

Отметим, что CurrentTool возвращает объект класса TLens. В действи¬ 
тельности данная функция всегда возвращает объект некоторого подкласса 
класса TLens, такого, как класса TPlanoConcaveLens. Наш проект структуры 
классов для линз определяет общее поведение линз в классе TLens. Поэто¬ 
му любой объект-пользователь, который имеет доступ к текущей сервисной 
программе палитры, может полностью манипулировать результирующим объ¬ 
ектом-линзой, даже если класс объекта мог быть неизвестным до момента 
выполнения. В ситуации, подобной данной, полиморфизм и динамическая 
связь служат наилучшим образом. К счастью, мы получили выигрыш в ста¬ 
тической проверке типов Object Pascal, потому что все результирующие объ¬ 
екты совместно используют общий класс-предок TLens. В соответствии с на¬ 
шей модульной архитектурой классы TOpticsView и TPaletteView объявлены 
в интерфейсе программного модуля UOpticsViews. 

Проектирование команд эксперимента. Проблемно-зависимые команды 
представляют собой другие классы существенные, для нашего проекта. Со¬ 
гласно требованиям, наше приложение должно поддерживать выбор новых 
линз вдоль оптической скамьи, выбор существующих линз и перемещение 
всех выбранных линз. Совместно с руководством интерфейса пользователя 
Macintosh наше приложение должно также поддерживать удаление, копиро¬ 
вание, чистку и вставку линз внутри как данного оптического эксперимента, 
так и в других экспериментах. МасАрр предусматривает класс TCommand 
как часть его механизма команд меню, и поэтому мы можем ввести под¬ 
классы данного класса для поддержки различных проблемно-зависимых ко¬ 
манд, которые нам необходимы. 
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На рис. 9-14 представлены наши проектные решения по этим классам. 
На самом нижнем уровне иерархии находится семь специализированных 
классов, которые являются подклассами класса TLensCommand. Последний в 
свою очередь является подклассом класса TCommand в МасАрр. Сначала мы 
сделали каждый из семи специализированных классов прямым наследником 
класса TCommand, но скоро мы обнаружили некий шаблон. Необходимо, 
чтобы каждый объект-команда имел поле, которое указывало бы на модель, 
на которую он воздействует, и для каждого объекта-команды необходимо со¬ 
вместно использовать общее поведение для ограниченного перемещения мы¬ 
ши. Поэтому мы ввели класс TLensCommand и перенесли все общее поведе¬ 
ние из семи специализированных классов в данный промежуточный класс. 

Мы можем записать интерфейс класса TLensCommand. Так как команда 
действует на линзы в оптическом эксперименте, мы должны включить поле, 
содержащее объект класса TOpticsModel. Поэтому, как нам станет очевидно 
позже, мы также включаем Вооіеап-поле, которое указывает, будет изобра¬ 
жаться на экране положение линз, которыми манипулирует данный объект 
команда, вдоль оптической оси или нет. 

Таким образом, мы можем записать 

TLensCommand - object (TCommand) 

fOpticsModel : TOpticsModel; 

fDrawPosition : Boolean; 

procedure TLensCommand.ILensCommand (ASuperView ; TView; 

AnOpticsModel : TOpticsModel; 

DrawPosition ; Boolean); 

procedure TLensCommand.TrackConstrain (AnchorPoint, 

PreviousPoint : VPoint; 

var NextPoint : VPoint); override; 


Интерфейсы всех семи специализированных классов очень похожи. Для 
большей части интерфейса мы должны переопределить такие операции, как 
Commit, Dolt, Undolt и Redolt, которые обеспечивают специфическое пове¬ 
дение для каждого класса и необходимы для поддержки механизма команд 
меню МасАрр. Каким образом эти методы вызываются? С помощью меха¬ 
низма главного цикла событий метод приложения HandleEvent первым реа¬ 
гирует на событие, извлекая метод DispatchEvent. Как только метод 
DispatchEvent выполнен, управление возвращается к HandleEvent, который 
затем извлекает метод приложения PerformCommand для обработки какой- 
либо команды, которую мог создать объект управления событием (например, 
через проблемно-зависимую реализацию метода DoMouseCommand). Метод 
PerformCommand выполняет наиболее важную часть работы, вызывая метод 
Dolt соответствующего объекта команды. Аналогично методы Undolt и 
Redolt вызываются объектом-приложением как часть его стандартных мето¬ 
дов управления меню. 

Сейчас мы можем записать интерфейс класса TSketcherCommand следу¬ 
ющим образом; 

TSketcherCommand - object (TLensCommand) 


(lens : Tlens; 



procedure TSketcherComt 
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mand.ILensCommand (ASuperView : TView; 

AnOpticsModel : TOpticsModel; 
DrawPosition : Boolean); override; 

procedure TSketcherCommand.Free; override; 

procedure TSketcherCommand.Commit; override; 

procedure TSkelcherCommand.DoIt; override; 

procedure TSketcherCommand.UndoIt; override; 

procedure TSketcherCommand.RedoIt; override; 

procedure TSketcherCommand.TrackFeedback (AnchorPoint, 

NextPoint : VPoint; 

TumltOn, 

MouseDidMove : Boolean); override; 

function TSketcherCommand.TrackMouse (ATrackPhase ; TrackPhase; 

var AnchorPoint, PreviousPoint, 

NextPoint : VPoint; 

MouseDidMove : Boolean) : TCommand; 
override; 


Поскольку объект выбор картинки должен выбрать линзу определенного 
типа, то этот класс включает поле fLens для сохранения данного состояния. 
Как мы увидим ниже, объект отображения отвечает за создание объекта-ко¬ 
манды «выбора картинки», затем устанавливает значение данного поля с 
помощью метода CurrentTool соответствующего объекта-палитры. 

Мы не будем показывать интерфейсы остальных специализированных 
классов, поскольку они аналогичны рассмотренным выше. Все семь классов, 
так же как и класс TLensCommand, объявляются в интерфейсе программно¬ 
го модуля UOpticsCoramands. Что представляет собой программный модуль 
UOpticsDialogs? Как правило, мы экспортировали неспециализированные ин¬ 
терфейсы для зависимых от приложения диалогов. Окна диалогов в общем 
случае конструируются на основе класса TDialogView в МасАрр: диалог 
обычно управляет экземплярами таких классов, как TPicture, TPopup, 
TButton, TEditText и TStaticText. Только в нескольких случаях требуется 
ввести новые подклассы диалогов, и фактически все эти классы могут быть 
скрыты в реализации программного модуля диалога. Поэтому мы можем ис¬ 
пользовать на высоком уровне абстракции программный модуль 
UOpticsDialogs для экспортирования набора общедоступных программ, кото¬ 
рые существуют только для вывода на экран диалогов и затем возврата 
значений, полученных в результате взаимодействия диалога с пользователем. 

Какие диалоги нам необходимы? Помимо тех проектных решений, кото¬ 
рые мы до сих пор рассматривали, существуют еще и другие проектные ре¬ 
шения. Теперь нам необходимо посмотреть на все с позиции пользователя 
интерфейса. Для решения нашей проблемы требуется основанная на окнах 
система, которая позволяет выбирать меню и поддерживает работу с 
мышью; кроме этого, у нас мало ориентиров. На этой стадии нашего проек¬ 
тирования мы ввели ядро приложения, состоящее из его ключевых классов 
и самых существенных механизмов. Теперь мы должны рассмотреть проект 
интерфейса пользователя. 
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Рис. 9-15. Проект окна инструментального средства разработки 
конструкций геометрической оптики. 

9.3. РАЗВИТИЕ 

Реализация интерфейса пользователя 

Искусство проектирования интерфейса пользователя ставит перед разра¬ 
ботчиком бесчисленное количество возможностей. Например, должны ли мы 
использовать простой процессор командной строки, или возможно вместо не¬ 
го спускающееся меню (или и то и другое)? Должны ли мы предполагать, 
что нашими выходными устройствами являются только простые, символьные 
терминалы, или у нас будут дисплеи, которые позволят нам изобретать дру¬ 
жественный интерфейс, используя составные перекрывающиеся окна с графи¬ 
ческими объектами отображения, которые могут быть помещены в подокна и 
снабжены звуковым сигналом? Что можно сказать о самих командах: долж¬ 
ны ли мы еще использовать краткие непонятные сокращения, такие, как 
grep или mkfs, или должны использовать длинные, значимые имена? Чело¬ 
веческий фактор, технические ограничения, исторические причины и личное 
предпочтение членов команды разработчиков — все эти обстоятельства дела¬ 
ют задачу создания полезного, выразительного, непротиворечивого интерфей¬ 
са человек-машина очень сложной. К счастью, стандартные интерфейсы 
пользователей, такие, как Motif [11], и программы, включенные в МасАрр, 
в течение долгого времени помогают разработчикам строить различные по 
виду и наполнению приложения. 

Как мы уже видели, мы можем отделить подробные проектные решения 
интерфейса пользователя от некоторых проектных решений программного 
обеспечения высокого уровня. Интерфейс пользователя, необходимый для ре¬ 
шения некоторых проблем, часто является всего лишь косметической оболоч¬ 
кой, которая окружает ядро приложения, и поэтому вполне можно создать 
несколько различных видов интерфейсов для одйой и той же системы. Для 
таких приложений, как инструментальное средство разработки конструкций 
геометрической оптики и различные программы изображения и рисования, 
интерфейс пользователя является больше, чем просто фасад; изящный и вы¬ 
разительный интерфейс пользователя существенно полезен для таких продук¬ 
тов. К счастью, прототипируя интерфейс пользователя, до того как мы пол- 
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ностью реализуем или даже спроектируем все необходимые механизмы, мы 
можем поддерживать обратную связь с возможными пользователями. Своев¬ 
ременная обратная связь с пользователями помогает настраивать семантику 
интерфейса и очищать его от идиосинкразических наростов, зазубрин и ца¬ 
рапин. 

Выбор МасАрр для нашей реализации непосредственно ограничивает 
возможности интерфейса пользователя. Эти ограничения, так же как и на¬ 
ши требования, означают, что мы предполагаем использовать окна, спускаю¬ 
щиеся меню и фактически целую гамму механизмов, описанных в стандарте 
интерфейса пользователя Macintosh. Таким образом, наша задача упрощается 
до проблемы, связанной с решением о внешнем виде различных окон и ди¬ 
алогов в нашем приложении, а также о выборе меню и команд. 

Проектирование окон. На рис. 9-15 показан макет окна, который мы 
можем использовать для изображения на экране оптического эксперимента, 
используя палитру и просматриваемый объект отображения. Палитра содер¬ 
жит указатель и шесть картинок сервисных программ, по одной для каждо¬ 
го типа линз. Пользователь может нажать и отпустить клавишу мыши на 
указателе или на любой сервисной программе для того, чтобы выбрать ее. 
Мы указываем на то, что определенный элемент палитры выбран с обра¬ 
щением его изображения. Мы также изображаем просматриваемый объект 
отображения с наибольшим количеством атрибутов, включая оптическую 
скамью, единственный действительный объект, горизонтальные и вертикаль¬ 
ные метки шкалы. 

Проектирование меню. Хотя стандарт интерфейса пользователя 
Macintosh предполагает, что все меню должны появиться на линейке меню, 
тем не менее существуют причины, по которым каждое приложение должно 
содержать определенные стандартные меню. Первое меню, которое 
необходимо иметь, — Apple -меню, на которое указывает символ @. Первый 
элемент в данном меню используется для вывода окна диалога, содержащего 
имя приложения, права на копирование и для некоторых приложений вспо¬ 
могательную информацию. В нашем приложении используется следующее 
имя для данного элемента: 

* About Optics... 

Многоточие указывает пользователю, что выбранный элемент меню вы¬ 
ведет на экран окна диалога. Оставшиеся элементы Apple -меню обычно по¬ 
священы настольной добавочной информации. 

Следующим стандартным меню является File -меню. Его цель — обеспе¬ 
чить простые команды для работы с файлами, такие, как Open, Close и 
Save. В него также включаются две команды вывода на печать и команда 
выхода из приложения. Мы включили следующие элементы в данное меню: 
New, Open, Close, Save, Save as..., Save to Copy..., Revert to Saved, Page 
Setup..., Print..., Quit. 

Некоторые из этих элементов, такие, как New, Open и Save, имеют 
эквиваленты в виде командных клавиш клавиатуры (Command-N, Command- 
0 и Command-S соответственно), определенных в стандарте интерфейса 
пользователя Macintosh. Некоторые элементы меню могут быть недоступны¬ 
ми в определенные моменты времени. Например, элемент Close должен 
быть доступным, только когда существует по крайней мере один открытый 
документ, а элемент Save должен быть доступным, только когда существует 
открытый документ, который был недавно изменен. Так как требования к 
приложению предусматривают управление не более чем четырьмя открытыми 
документами одновременно, то мы имеем доступными New и Open только 
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тогда, когда существует меньше чем четыре открытых документа в настоя¬ 
щий момент. Для того чтобы была более тесная обратная связь в случае, 
когда пользователь создает или открывает документ, мы решили ввести диа¬ 
лог, который предупреждает пользователя, пытающегося открыть более четы¬ 
рех документов. Третье стандартное меню Edit обычно включает команды 
удалить, передвинуть и скопировать объекты. Мы включаем следующие эле¬ 
менты в данное меню: Undo, Cut, Copy, Paste, Clear, Select All, Show 
Clipboard. 

Большинство из этих элементов имеют стандартные эквиваленты в виде 
командных клавиш клавиатуры. Когда пользователь вырезает или копирует 
выбранные элементы, они помещаются в специальный объект отображения, 
называемый буфером вырезанного изображения. Элементы могут быть поме¬ 
щены из буфера вырезанного изображения обратно в эксперимент. Так как 
содержание буфера вырезанного отображения продолжает существовать после 
выхода из приложения, пользователь может вырезать и вставить элементы 
среди приложений, предполагая, что приложения соответствуют значениям 
элементов. Команда Show Clipboard изображает на экране буфер вырезанно¬ 
го изображения объекта отображения, так что можно видеть недавно выре¬ 
занные или скопированные объекты. 

Рассмотрим теперь нестандартное меню. Мы изобретаем эти меню и их 
элементы, задаваясь вопросом, какие операции пользователь может произво¬ 
дить над приложением как над единым целым. Не все такие операции в 
отличие от элементов меню являются удобными. Например, выбор, переме¬ 
щение и выбор картинки сервисной программы лучше выполняются с 
помощью действий мыши. Тем не менее существует несколько типов опера¬ 
ций, не связанных с мышью: команды для изображения на экране различ¬ 
ных атрибутов объектов отображения, команды для фокусирования на одном 
из четырех открытых документов и команды для изображения свойств вы¬ 
бранных линз. Мы размещаем эти команды в одном из двух меню. Первое 
меню, называемое View, содержит следующие элементы: 

* Drawing Size... 

* Show Optical Bench 

* Show Grid Lines 

* Show Page Breaks 

* Enable Autogrid 

Выбор первого элемента в данном меню выводит на экран окно диало¬ 
га, с помощью которого пользователь может регулировать размер объекта 
отображения, округляя его до размера ближайшей наибольшей страницы. 
Оставшиеся четыре элемента меню являются командами переключения, ко¬ 
торые отражают состояние отдельных атрибутов. Например, когда оптическая 
скамья невидима в настоящий момент, второй элемент меню читается, как 
указано выше. Когда этот элемент выбран, оптическая скамья изображается 
и данный элемент изменяется на Hide Optical Bench. 

Оставшиеся три элемента меню имеют аналогичное поведение. Мы вы¬ 
зываем следующее меню Experiments и оно содержит следующие элементы: 

* «.,.» 

* «...» 

* «...» 

* «...» 

* Lens Specifications... 
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Первые четыре элемента представляют имена каждого из четырех доку¬ 
ментов. Всякий раз когда существующий эксперимент открывается, мы хо¬ 
тим, чтобы его имя появилось как элемент в данном меню. Если это новый 
документ, имя ему дается приложением (в форме Untitled п, іде п — мо¬ 
нотонно возрастающее число, установленное приложением). Когда приложе¬ 
ние закрывается, его имя убирается из меню, и другие имена перемещаются 
вверх в списке. Мы должны также не забыть переименовать документ, ког¬ 
да пользователь выбирает элемент Save as... из File -меню. Когда пользова¬ 
тель выбирает элемент из Experiment -меню, указывающий на отдельный до¬ 
кумент, мы хотим, чтобы приложение вывело соответствующее окно как 
внешнее, так чтобы пользователь мог легко найти эксперимент среди всех 
окон, которые могут загромождать экран. 

Последний элемент в данном меню LensSpecifications.. является доступ¬ 
ным, только когда выбрана одна единственная линза. Когда пользователь 
выбирает данный элемент, появляется окно диалога, которое показывает тип 
линзы, ее положение вдоль оптической скамьи и ее фокусное расстояние. 
Мы позволим пользователю редактировать только фокусное расстояние лин¬ 
зы, как это определяется нашими требованиями. 

Мы уже говорили выше, что такие ресурсы, как меню, лучше опреде¬ 
лены в ресурсном файле, поэтому мы можем изменить внешний вид прило¬ 
жения без изменения его исходного текста. Например, мы можем отразить 
наши решения проектирования, касающиеся содержания View -меню включив 
следующее в наш ресурсный файл: 

resource ’omnu’ (4) { 

4 , 

nextMenuProc, 

Allitems & - (Menultem2 I Menultem6), 

enabled, 

"View", 

{/• {1} V "Drawing Size...”, noicon, plain, 1001; 

/* [2] */ noicon, plain, nocommand; 

/• [3] »/ "Show Optical Bench", nolcon, plain, 1002; 

/* 14] •/ "Show Grid Lines", nolcon, plain, 1003; 

/* [51 */ "Show Page Breaks", nolcon, " ", " ", plain, 1004; 

/* 16] */ nolcon, plain, nocommand; 

/* [7] •/ "Enable Autogrid", nolcon, plain, 1005} 


Проектирование диалога. Четыре связанных друг с другом диалога со¬ 
ответствуют меню AboutOptics...; диалог предупреждения для использования, 
когда четыре документа уже открыты и пользователь старается создать или 
открыть еще один документ; Drawing Size... диалог; Lens Specification... диа¬ 
лог. Неважно, что мы реализуем эти диалоги сейчас, но поскольку мы хо¬ 
тим, чтобы они имели единообразный вид и наполнение, важно проектиро¬ 
вать их в одном и том же стиле. Поэтому в нашей модульной архитектуре 
мы поместили все диалоги в программный модуль UOpticsDialogs: 
размещаясь в одном программном модуле, они могут совместно использовать 
все принципы реализации. 

На рис. 9-16 показаны макеты двух наиболее важных диалогов. Диалог 
Drawing Size... является достаточно сложным. Пользователь может выбрать 
направление, в котором нумеруются страницы (с помощью двух радиокла¬ 
виш), так же как размер страницы (нажимая и отпуская клавишу мыши на 
сетке, которая в свою очередь обновляет сетку, выделяя и высоту, и 
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ширину статических текстовых элементов). Диалог сложен для реализации, 
хотя пользователь интуитивно это понимает, отчасти из-за того, что сетка 
может изменяться в зависимости от типа выходного устройства и направле¬ 
ния вывода на печать, увеличения и размера бумаги выбранного пользовате¬ 
лем. Второй диалог, используемый в команде Lens Specifications, намного 
проще; он только позволяет пользователю редактировать фокусное расстоя¬ 
ние, показанное в диалоге. Теперь мы можем создать интерфейс для этих 
диалогов: 

unit UOpticsDialogs; interface 
uses 

UMacApp, UPrinting, UDialog, ToolUtils, Packages, 

UOpticsModels; 

{$S UDial} 

procedure InitializeOpticsDialogs; 
procedure DisplayAboutOpticsDialog; 
procedure DispIayNoMoreDocumentsDialog; 

procedure DisplayDrawingSizeDialog (CurrentModelSize : Point; 

CurrentResolution : Point; 

CurrentPageSize : VPoint; 
var CurrentViewSize ; VPoint; 
var CurrentDirection : VhSelect; 
var AcceptChanges : Boolean); 
procedure DisplayLensSpecificationDialog (SelectedLens : TLens; 

var NewFocalLength : FocalLength; 
var AcceptChanges : Boolean); 

implementation 

{$1 UOpticsDialogs.incl.p} 

end. 

Для полноты мы должны обеспечить полный интерфейс с данным моду¬ 
лем. Отметим использование предложений: мы доказываем зависимость от 
такого модуля других модулей, которые являются частью МасАрр (такие, 
как UMacApp, UPrinting и UDialog) и частью исходного кода нашего прило¬ 
жения (такое, как UOpticsModels). Отметим также директиву компилятора 
($SUDial), которая указывает, что весь скомпилированный код помещается в 
сегменте, называемом UDial. Наконец, общедоступная процедура 
InitializeOpticsDialogs существует для того, чтобы инициализировать состоя¬ 
ния определенного модуля (такого как модуля диалога МасАрр). 

Реализация классов интерфейса пользователя. На данном этапе мы 
можем реализовать все интерфейсные модули, которые спроектировали. Так 
как эта книга посвящена проектированию, а не кодированию, то мы не 
обеспечиваем здесь полную реализацию данной программы. Кроме того, ко¬ 
нечная реализация состоит из более 3000 строк Object Pascal и почти 2000 
строк исходного текста в ресурсном файле (с другой стороны, можете ли вы 
представить проектирование без использования богатой библиотеки классов, 
такой, как МасАрр). Тем не менее существуют еще разделы проектирова¬ 
ния, которые заслуживают обсуждения. В частности, мы должны показать, 
как наше проектирование строится на основе механизмов МасАрр. Мы так¬ 
же хотим продемонстрировать, как определенное представление решений ес¬ 
тественно следует решениям интерфейса. В конце мы хотим показать, как 
при использовании методов объектно-ориентированного проектирования про¬ 
ект системы развивается и реализуется. 

20 Гради Буч 
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Рис. 9-16. Диалоги инструментального средства разработки 
конструкций геометрической оптики. 

Реализацию можно начинать с любого тела модуля, но мы начинаем с 
классов, которые обеспечивают каркас приложения и интерфейс пользовате¬ 
ля, поэтому мы можем непосредственно получить полностью выполняемые 
системы. Поэтому начнем с класса TOpticDocumentManager. 

Выше мы проектировали меню и элементы меню, используемые в инст¬ 
рументальном средстве разработки конструкций геометрической оптики. Ис¬ 
ходя из требований пользователя, эти команды представляют действия, 
которые не связаны с мышью и выполняются как над единым целым. Так 
как наш проект состоит из объектов, которые объединяются для 
определенной функции, каждый объект отвечает за то, что он знает о со¬ 
стоянии приложения и внутренних механизмах. Вывод из этого правила за¬ 
ключается в том, что определенные объекты знают, как реагировать на не¬ 
которые, но не на все, команды меню. Хороший пример такого поведения 
приведен из класса TOpticsApplications. Экземпляры этого класса контро¬ 
лируют вхождение и прохождение документов, так как объект-приложения 
находится на более высоком уровне, чем объект-документ. В противополож¬ 
ность этому приложение ничего не знает об атрибутах объектов отображе¬ 
ния, потому что объекты отображения находятся на слишком низком уровне 
абстракции относительно объекта-приложения. Таким образом, объект-прило¬ 
жение является лучшим посредником в системе, способным отвечать за уп¬ 
равление только определенными командами меню такими как New, Open и 
Quit. Большинство стандартных команд (такие, как Quit) автоматически уп¬ 
равляются МасАрр. Тем не менее нам необходимо слегка изменить поведе¬ 
ние для New и Open, так как приложение должно управлять не более чем 
четыремя документами. Наш проект обеспечивает это в классе 
TOpticsDocumentHandler, поэтому объект управления документом должен ра¬ 
ботать вместе с объектом-приложением. Следовательно, мы должны заменить 
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метод DoMenuCommand в классе TOpticsApplications, который мы можем ре¬ 
ализовать, следующим образом: 

function TOpticsApplication.DoMenuCommand (ACmdNumber : CmdNumber) : TCommand; 

override; 

begin 

DoMenuCommand CNoChangea; 
case ACmdNumber of 
cAboutApp: 

Display AboutOpticsDialog; 
cNew, cOpen: 

if fOpticsDocumentManager.CanAddDocument then 

DoMenuCommand inherited DoMenuCommand (ACmdNumber) 
else 

DisplayNoMoreDocumentsDialog; 
kDocumentA .. kDocumentD; 

fOpticsDocumentManager.FocusOnADocument (ACmdNumber); 
cSave, cSaveAs, cSaveCopy: 

fOpticsDocumentManager.RenameDocument 

(TOpticsDocument (GetActiveWindowDocument)); 

otherwise 

DoMenuCommand inherited DoMenuCommand (ACmdNumber); 




Реализация данного метода вполне типична для объектно-ориентирован¬ 
ных систем: она является краткой и использует методы низкого уровня. Об¬ 
щей формой DoMenuCommand является большой оператор выбора, вклю¬ 
чающий только те элементы, которыми мы можем локально управлять: кон¬ 
станты, такие, как cAboutApp (определенная в МасАрр) и kDocumentA (оп¬ 
ределенная в нашем приложении). Константы kDocumentA через константы 
kDocumentD представляют собой командные числа, соответствующие первым 
четырем элементам меню Experiments диалога. Оператор выбора заканчива¬ 
ется конструкцией Otherwise, вызывающей соответствующий метод подкласса 
для управления командами, которые мы не можем локально обрабатывать. 

Отметим, что в данном исходном тексте наиболее интересная работа 
выполняется посредником, на который указывает поле 
fOpticsDocumentManager. Объект-приложение и объект-управление документом 
взаимодействуют очень сложным способом. Например, когда вызывается ко¬ 
манда Open и вызов метода CanAddDocument возвращает True, контроль пе¬ 
реходит к методу DoMenuCommand суперкласса приложения. В текущем со¬ 
стоянии в МасАрр выводится диалог, с помощью которого пользователь мо¬ 
жет выбрать документ и затем открыть его. Вызов метода AddDocument, оп¬ 
ределенного для объекта-приложения, осуществляется как часть этого 
механизма. В нашем проекте интерфейса класса текущий метод 
AddDocument замещается на собственный, который мы можем реализовать 
следующим образом: 

procedure TOpticsApplication.AddDocument (ANewDocument ; TDocument); override; 
begin 

fOpticsDocumentManager.AddDocument (TOpticsDocument (ANewDocument)); 

inherited AddDocument (ANewDocument); 
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Здесь мы в первую очередь ищем цель управления документом, так 
чтобы соответственно модифицировать Experiments -меню и затем вызвать те¬ 
кущее поведение, определенное в нашем методе суперкласса. 

Концептуально объект управления документом должен содержать путь 
от одного документа к четырем документам. МасАрр уже поддерживает 
несколько открытых документов в глобальной переменной gDocList, и 
поэтому неразумно ссылаться на объект из нескольких других объектов. Тем 
не менее запомним, что объект управления документом отслеживает свои 
документы по-другому, чем МасАрр: это является фактически проблемно-за¬ 
висимым поведением. В частности, объекту управления документом нужно 
знать три параметра для того, чтобы выполнять свою работу: соответствую¬ 
щее командное число для документа, отображение командного числа на оп¬ 
ределенный элемент меню и число открытых документов. 

Данная информация представляет состояние объекта управления доку¬ 
ментом, и, таким образом, мы можем выбрать представление для данного 
класса: 

fCmdToDocMap : array (kDocumenlA .. kDocumentD] of TOpticsDocument; 

fCmdToMenuItemMap : array [kDocumenlA .. kDocumentD] of Integer; 

fNumberOfDocuments : Integer; 

Первое поле fCmdToDocMap представляет отображение командного чис¬ 
ла на объект-документ. Это отображение обеспечивает значительно большее 
содержание информации, чем в простом списке, содержащемся в глобальной 
переменной gDocList. Второе поле fCmdToMenuItemMap обеспечивает отобра¬ 
жение каждого командного числа на элемент менкУ. При определении наше¬ 
го собственного локального состояния мы точно кешируем информацию, ко¬ 
торая нам нужна, и заканчиваем эффективной во времени реализацией. 
Имеется такое же разумное объяснение для включения третьего поля 
fNumberOfDocuments. Мы могли так же легко получить это число путем 
просмотра списка, содержащегося в gDocList. Тем не менее сохранение дан¬ 
ного локального состояния делает реализацию более быстрой (мы не вы¬ 
зываем метод другого объекта) и (мы в этом уверены) более понятной. Ко¬ 
нечно, компромисс заключается в том, что мы должны сохранять данное ло¬ 
кальное состояние согласующимся с соответствующим внешним состоянием. 

Отметим, что реализация, которую мы выбрали для класса 
TOpticsDocumentManager, является одним из возможных подходов. Мы вы¬ 
брали именно это представление, потому что решили пожертвовать про¬ 
странством для скорости. Если бы после построения приложения мы поняли, 
что то, что мы сделали, не имеет смысла (возможно, потому, что наше 
приложение имело ограничения по памяти), то у нас не было иного выхо¬ 
да, как изменить реализацию данного класса. Но поскольку мы спроектиро¬ 
вали данный класс, рассматривая его абстрактное поведение до реализации, 
мы могли выбрать альтернативное представление, не затрагивая ожиданий 
других обьектов-пользователей. Мы будем иметь некоторую рекомпиляцию, 
но так как мы завершаем изменения только представлением данного класса 
(который в большей степени невидим), нелогично изменять семантику любо¬ 
го другого объекта или класса, который зависит от TOpticsDocumentManager. 

В реализации метода AddDocument в классе TOpticsApplications мы вы¬ 
зываем метод с тем же именем, определенным в классе 
TOpticsDocumentManager. Так как мы выбрали представление, то теперь мы 
можем реализовать данный метод следующим образом: 
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procedure TOpticsDocumentManager.AddDocument (ADocument : TOpticsDocument); 


Index : Integer; 

Menu : MenuHandle; 

Title : Str255; 


for Index kDocumentA to kDocumentD do 
if (fCmdToDocMap [Index] - nil) then 
begin 

fCmdToDocMap [Index] ADocument; 

Menu ;- GetMenu (kExperimentsMenu); 

HLock (Handle (ADocument-fTitle); 

Title ADocument-fTitle; 

HUnlock (Handle (ADocument-fTitle); 

Setltem (Menu, fCmdToMenuItemMap [Index], Title); 
ADocument.fCommand Index; 


fNumberO(Documents fNumberOfDocuments + 1; 


На этом этапе мы модифицируем состояние карт, которые локальны 
для объекта управления документом, и строим операции низкого уровня (та¬ 
кие, как функция GetMenu из Пакета разработчика Macintosh). В 
результате мы устанавливаем имя соответствующего элемента в Experiments - 
меню при вызове процедуры Setltem. Отметим, что мы должны поддержи¬ 
вать отображение документа на его команду для того, чтобы выполнить ме¬ 
тоды DeleteDocument и RenameDocument; например, когда документ переиме¬ 
нован, мы должны изменить имя элемента меню, соответствующего этому 
документу путем сохранения командного числа в поле, определенном для 
этого объекта документа. Как мы узнаем, что нужно включить именно этот 
элемент меню? Для этого надо воспользоваться методом DoSetUpMenus объ¬ 
екта управления документом. 

Когда пользователь выбирает элемент меню в Experiments -меню, вызов 
метода DoMenuCommand объекта-приложения в результате приводит к 
вызову метода FocusOnADocument, определенного в классе 
TOpticsDocumentManager. Данный метод затем использует состояние в табли¬ 
це командное число/документ (как установлено выше) для активизации до¬ 
кумента, соответствующего этому элементу: 

procedure TOpticsDocumentManagcr.FocusOnADocument (ACmdNumber :CmdNumber); 
begin 

fCmdToDocMap [ACmdNumber] .fOpticsWindow. Activate (True); 
fCmdToDocMap [ACmdNumber] .fOpticsWindow.Select; 

end; 


Таким образом, объекты-приложения обладают определенной информа¬ 
цией о документах, но только объекты управления документами знают о со¬ 
ответствующих командных числах и документах. 

Метод DoMakeDocument, определенный в классе TOpticsApplications, вы¬ 
зывается при создании или открытии существующего документа. Поэтому в 
нашей реализации данного метода должен создаваться и инициализироваться 
объект-документ, который становится частью состояния приложения: 

function TOpticsAppUcation.DoMakeDocument 

(ItsCmdNumber : CmdNumber) : TDocument; override; 
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OpticsDocument : TOpticsDocument; 

begin 

new (OpticsDocument); 
OpticsDocument.IOpticsDocument; 
DoMakeDocument OpticsDocument; 


Здесь опять мы имеем краткую реализацию, построенную на основе аб¬ 
стракций нижнего уровня. 

Обращаясь к классу TOpticsDocument, заметим, что он представляет 
проблемно-зависимую конкретизацию встроенного в МасАрр класса 
TDocument. Подобно последнему, он участвует в механизме документов 
МасАрр и поэтому должен знать, как считать и записывать оптический экс¬ 
перимент. Дополнительно объект-документ должен отвечать за управление 
окнами, связанными с документом. В результате, мы должны поддерживать 
поля для окон, просматриваемые объекты отображения и палитру, связанную 
с документом. Как мы уже говорили выше о механизме документов 
МасАрр, мы должны также поддерживать объект, представляющий оптиче¬ 
ский эксперимент. Таким образом, мы можем завершить реализацию класса, 
объявив его в определении класса, которое содержится в интерфейсе модуля 
U OpticsDocuments: 


fOpticsModel 

fOptlcsWindow 

fOpticsView 

fPaletteView 

(Command 


: TOpticsModel; 
; TWindow; 

: TopticsView; 

: TPaletteView; 

: Integer; 


Поле fCommand было получено, так как нам необходимо поддерживать 
отображение документа на командное число в реализации метода 
TOpticsDocumentManager. 

Когда документ создан или открыт, текущее поведение МасАрр сначала 
создает объект-документ с помощью метода DoMakeDocument объекта-прило¬ 
жения. Если этот документ не является только что созданным, устойчивое 
состояние документа считывается с диска, в результате чего вызывается ме¬ 
тод DoRead объекта-документа. Обычно мы реализуем данный метод путем 
построения на основе абстракций нижнего уровня: 

procedure TOpticsDocument.DoRead (ARefNum : Integer, 

RsrcExists, 

ForPrinting ; Boolean); override; 

begin 

inherited DoRead (ARefNum, RsrcExists, ForPrinting); 
fOpticsModel.DoRead (ARefNum); 


Как для новых, так и для старых документов МасАрр следующим из¬ 
влекает методы DoMakeViews и DoMakeWondows. Опять мы реализуем эти 
методы путем построения на основе абстракций нижнего уровня: 

procedure TOpticsDocument.DoMakeViews (ForPrinting ; Boolean); override; 
var 

PaletteView : TPaletteView; 

OpticsView : TOpticsView; 
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begin 

new (PalleteVlew); 

PaletteVlew.IPaletteVlew(self, fOpUcsModel); 
fPaletleView PaletleView; 
new (OpticsView); 

OptlcsView.IOpticsView (self, PaletleView, fOpUcsModel); 
fOptlcaView OpticsView; 
fOpticsModcl.fView OpticsView; 

end; 


procedure TOpttcsDocument.DoMakeWindows; override; 
a Window : TWindow; 

begin 

aWindow NewPaletteWindow (kWlndowResource, kWantHScrollBar, 

kWantVScrollBar, self, 
fOpticsView, fPaletleView, 
kPalettelmage Width, kLeftPalette); 

aWindow.AdaptToScreen; 
fOpticsWindow aWindow; 

end; 

В методе DoMakeWindows мы используем общедоступную процедуру 
NewPaletteWindow для создания окна согласно проекту, показанному на 
рис. 9-15. 

Как мы видим, в методе DoMakeViews рождение объекта отображения 
сначала предполагает его создание, а затем его инициализацию. Инициали¬ 
зация объекта в основном существует для установки его первоначального ус¬ 
тойчивого состояния. Например, инициализация оптического объекта отобра¬ 
жения происходит следующим образом; 

procedure TOpticsView.IOpticsView (ADocument : TDocument; 

APalette : TPaletteView; 

AModel : TOpticsModel); 
var 

Size : VPoint; 

OpticalBench : TOpticalBench; 

APrintHandler : TOpticsPrintHandler; 

begin 

SetVPKSize, 100, 100); 

IView(ADocument, nil, gZeroVPT, Size, SizeFillPages, SizeFillPages); 
fPaletteView APalette; 
fOpticsModel AModel; 
new(OpticalBench); 

OpticaiBench.IOpticalBench (self); 
fOpticalBench OpticalBench; 
fDrawOpticalBench True; 
fDrawGridLines False; 
fDrawPageBreaks False; 
fAutoGridEnabled True; 
new(APrintHandler); 

APrintllandler.lStdPrintHandlerfADocument, self. False, True, True); 
APrintHandler.fShowBreaks fDrawPageBreaks; 

APrintHandler.fMinimalMargins True; 

APrintHandler.fPageDirection H; 

end; 

Инициализация обычно включает вызов метода инициализации, опреде¬ 
ленного в суперклассе и следующего перед операторами, которые устанавли- 
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ваюі значения различных полей. Мы устанавливаем значения всех полей, 
чтобы ни один из объектов-пользователей не был захвачен врасплох. 
Отметим, что мы создаем объект управления выводом на печать как часть 
инициализации оптического объекта отображения, и он включает знания о 
том, как выводить на печать содержимое объекта отображения. Так как мы 
не заботились о текущем изображении на экране страниц прерываний в 
МасАрр, мы создаем свой собственный класс управления выводом на печать 
так, что мы можем заменять текущее поведение (в частности, мы хотим 
чтобы номера страниц были изображены во всех углах страницы, а МасАрр 
показывает только некоторые из этих цифр). Почему мы не говорили об 
этом выше, когда реализовывали интерфейс для большинства модулей? Это 
объясняется тем, что данный новый класс TOpticsPrintHandler должен быть 
видимым только для реализации класса оптических объектов отображения. 
Поэтому мы можем закрыть данный класс от других объектов-пользователей, 
объявив это в реализации модуля TOpticsViews. 

Оптический объект отображения участвует в механизме отображения 
МасАрр и поэтому мы должны заменить текущий метод Draw в интерфейсе 
нашего класса. Оптический объект отображения должен выводить на экран 
не только изображение оптического эксперимента, но также различные атри¬ 
буты, такие, как метки шкалы и оптическую скамью. Мы должны прини¬ 
мать это во внимание при реализации метода Draw: 

procedure TOpticsView.Draw (Area : Rect); override; 
begin 

inherited Draw(Area); 

if (fDrawGridLines and (not gPrinting)) then 
DrawGridLines(Area); 
if fDrawOpticalBench.Draw(Area); 

fOpticalBench.Draw (Area); 
fOpticsModel.Draw(Area, fDrawOpticalBench); 

end; 


Мы могли бы записать исходный текст, который изображает метки 
шкалы в заданном месте, но путем определения метода DrawGridLines мы 
упростили реализацию метода Draw и сделали его более понятным. Это яв¬ 
ляется примером совместного действия объектно-ориентированного проектиро¬ 
вания и более традиционных методов структурного проектирования. В объек¬ 
тно-ориентированном проектировании мы начинаем с определения классов и 
объектов, но часто производим декомпозицию сложных методов в небольшие 
алгоритмические абстракции. 

Так же как приложение и объекты-документы, оптический объект ото¬ 
бражения участвует в механизме команд меню МасАрр. Действительно, оп¬ 
тический объект отображения знает лучше, как реагировать на следующие 
команды: Cut, Copy, Show Optical Bench и Show Page Breaks. МасАрр дела¬ 
ет вызов метода DoSetUpMenus для каждого объекта, включенного в коман¬ 
дную цепочку. Для этого необходимо сделать доступными команды, которые 
для него представляют интерес. Итак, мы можем реализовать данный метод 
для класса TOpticsView следующим образом: 

procedure TOpticsView.DoSetUpMenus; override; 

ѵаг Count : Integer; 

begin 


inherited DoSetUpMenus; 
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Count fOpticsModel.NuraberOfSelections; 

Enable (cCut, (Count >0)); 

Enable(cCopy, (Count > 0)); 

CanPaste (kClipType); 

Enable (cClear, (Count >0)); 

Enable(cCopy, (Count > 0)); 

CanPaste(kClipType); 

Enable (cClear, (Count >0)); 

Enable (cSelectAll, (Count < fOpticsModel.NumberOfLenses)); 

Enable(kDrawingSize, True); 

Enable(kShowOpticalBench, True); 

SetMenuState (kShowOpticalBench, kStringResource, kDrawOpticalBench, 

kDontDrawOpticalBench, fDrawOpticalBench); 

Enable(kShowGridLines, True); 

SetMenuState (kShowGridLines, kStringResource, kDrawGridLines, 

kDontDrawGridLines, fDrawGridLines); 

Enable (kShowPageBreaks, True); 

SetMenuState (kShowPageBreaks, kStringResource, kDrawPageBreaks, 

kDontDrawPageBreaks, rorawPageBreaks); 
Enable(kEnableAutoGrid, True); 

SetMenuState (kEnableAutoGrid, kStringResource, kUseAutoGrid, 

kDontUseAutoGrid, fAutoGridEnabled); 

Enable(kLensSpecification, (Count - D); 


Заметим, что нам предоставлены только те элементы меню, на которые 
оптические объекты отображения могут реагировать, и критерий, по которо¬ 
му нам предоставляется команда, различен для каждого элемента меню. На¬ 
пример, предоставляется команда Cut, только если существует более чем 
один выбранный объект в оптической модели. С другой стороны, предостав¬ 
ляется команда Select АН, только если в модели существуют некоторые объ¬ 
екты, которые еще не выбраны. Такие элементы меню, как Show Optical 
Bench, предоставляются согласно значению соответствующего поля в оптиче¬ 
ских объектах отображения. Вызов процедуры SetMenuState считывает одно 
из двух имен элементов меню из ресурсного файла согласно булевой вели¬ 
чине, которая дается как параметр. 

Если объекту предоставлен индивидуальный элемент меню, он в общем 
случае будет также обрабатывать эту команду всякий раз, когда выбран 
данный элемент меню. Это правило, в частности, справедливо для класса 
TOpticsView. В классе TOpticsApplication мы выполняем метод 
DoMenuCommand, вызывая абстракции нижнего уровня. Мы будем 
выполнять то же самое и здесь, но дважды, так как команды, которые мо¬ 
гут обработать оптический объект отображения, являются тривиальными. На¬ 
пример, при выборе команды ShowOpticalBench (или Hide OpticalBench в за¬ 
висимости от состояния поля fDrawOpticalBench) просто переключается состо¬ 
яние поля и изменяется соответствующий атрибутивный объект отображения. 
Нет необходимости в том, чтобы эта команда была отменяемой, так как 
пользователь может сделать обратное действие, выбрав снова тот же элемент 
меню. Следовательно, создавать объект-команду для выполнения этих дейст¬ 
вий излишне. С другой стороны, все команды редактирования, включая Cut, 
Show, Paste и Clear, являются отменяемыми. Пользователю, который «выре¬ 
жет* линзу и затем поймет, что это действие было неправильным, будет 
предоставлена возможность отменить команду и, таким образом, вернуть 
эксперимент в первоначальное состояние. Так как объекты-команды содержат 
знания о том, как выполнять, отменять и переделывать действие, хорошо, 
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что наше приложение создает объекты-команды, которые действуют как по- 
средники, отвечающие за выполнение этих действий. 

Реализация метода DoMenuCommand класса TOpticsView является 
долгой процедурой, потому что существует слишком много команд, которы¬ 
ми он может управлять. Концептуально реальная работа производится где- 
нибудь в другом месте: 

function TOpticsView.DoMenu 

Proceed 

CurrentModelSize 

CurrentDirection 

CurrentResolution 

CurrentPageSize 

CurrentViewSize 

AcceptChanges 

PageS trips 

SelectedLens 

NewFocalLength 

CutCommand 

CopyCommand 

Paste Command 
ClearCommand 

Command (ACmdNumber : CmdNumber) : TCommand; override; 

Boolean; 

Point; 

VHSelect; 

Point; 

VPoint; 

VPoint; 

Boolean; 

Point; 

TLens; 

FocalLength; 

TCutCommand; 

TCopyCommand; 

TPasteCommand; 

TClearCommand; 

function CheckLens (Item : TLens) : Boolean; 
begin 

CheckLens Item.flsSelected; 
end; 
begin 

DoMenuCommand gNoChanges; 

case ACmdNumber of 
cSelectAII: 

fOpticsModel.SelectAU; 

cCut: 

begin 

new(CutCommand); 

CutCommand.ILensCommand(self, fOpticsModel, False); 

DoMenuCommand CutCommand; 

cCopy: 

begin 

new(CopyCommand); 

CopyCommand.ILensCommand(self, fOpticsModel, False); 

DoMenuCommand CopyCommand; 

cPaste: 

begin 

new(PasteCommand); 

PasteCommand.ILensCommand(self, fOpticsModel, False); 

DoMenuCommand PasteCommand; 

cClear: 

begin 

new (ClearCommand); 

ClearCommand.ILensCommand(self, fOpticsModel, False); 

DoMenuCommand ClearCommand; 

kDrawingSize: 
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begin 

CurrentModeiSize fOpticsModel.CurrentSize; 

CurremDireclion 

TStdPrintHandler(fPrintHandler) .fPageDirection; 
CurrentResolution fPrintHandler.fEffectlveDeviceRes; 
CurrentPageSize fPrinlHandler.fViewPerPage; 

CurrentViewSize fSlze; 

DisplayDrawingSizeDialog (CurrentModeiSize, CurrentResolution, 
CurrentPageSize, CurrentViewSize, 
CurrentDirection, AcceptChanges); 

if AcceptChanges then 
begin 

if not EqualVPUCurrentViewSize, fSize) then 

Resize(CurrentViewSize.H, CurrentViewSize.V, True); 
if (CurrentDirection <> 

TStdPrintHandler(fPrintHandler) .fPageDirection) then 
TStdPrintHandler(fPrintHandler) .fPageDirection 
CurrentDirection; 

ForceRedraw; 

end; 

kShowOpticalBench: 

ToggleDrawOpticalBench; 

kShowGridLines: 

ToddieDrawGridUnes; 

kShowPageBreaks: 

ToggleDrawPageBreaks; 

kEnableAutoGrid: 

ToggleAutoGridEnabled; 

kLensSpecification; 

begin 

if (fOpticsModel.NumberOfSelections - 1) then 
begin 

SelectedLens 

TLens(fOpticsModel.FirstLensThat (CheckLens)); 
DisplayLensSpecificationDialog (SelectedLens, 

NewFocalLength, 

AcceptChanger); 

if AcceptChanges then 
begin 

SelectedLens.SetFocalLength (NewFocalLength); 
fDocument.fChangeCount fDocument.fChangeCount +1; 

otherwise 

DoMenuCommand inherited DoMenuCommand (ACmdNumber); 


В данном методе мы управляем командами Select All, Drawing Size..., 
Show Optical Bench, Show Grid Lines, Show Page Breaks, Enable Autogrid и 
Lens Specification... в соответствующих местах. Эти команды не являются от¬ 
меняемыми, но все другие команды — отменяемые. Таким образом, выпол¬ 
нение различных команд редактирования сначала включает создание объек¬ 
та-команды соответствующего класса и затем его инициализацию. Только 
что созданный объект-команда возвращается обратно как результат функции 
метода DoMenuCommand. Согласно механизму команд меню МасАрр, метод 
PerformCommand объекта-приложения в конечном счете получает данный 
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объект-команду, а затем метод PerformCommand вызывает Dolt объекта- 
команды. 

Заметим, что наш метод содержит некоторое количество исходного тек¬ 
ста для выполнения команд Drawing Size... и Lens Specification.... В обоих 
случаях выполнение включает нахождение определенного состояния, необхо¬ 
димого для диалога, вызов общедоступной процедуры, соответствующей это¬ 
му диалогу, затем изменение состояния объекта отображения, если пользова¬ 
тель в действительности редактировал диалог и устанавливал его новые зна¬ 
чения. Эти преимущества использования ресурсов диалогов очевидны. 

Метод DoMouseCommand участвует в механизме действия мыши МасАрр 
и с точки зрения его реализации он похож на метод DoMenuCommand. По¬ 
скольку мы хотим, чтобы все действия мыши — выбор, перемещение, выбор 
картинки сервисной программы — были отменяемыми, данный метод должен 
создавать один из нескольких объектов-команд. Как он узнает, какой объ¬ 
ект-команду создавать? Ответ на этот вопрос зависит от состояния объекта- 
палитры. Если пользователь выбрал для линзы определенную сервисную 
программу, действие мыши в оптическом объекте отображения представляет 
начало работы с эскизом линзы. Если пользователь выбрал сервисную про¬ 
грамму, позволяющую указывать на линзы, действие мыши в оптическом 
объекте отображения представляет собой групповой выбор (если курсор мы¬ 
ши не находится под какой-либо линзой) или начало перемещения (если 
существуют выбранные линзы или курсор мыши находится под линзой). Мы 
можем выразить данный алгоритм следующим образом: 


function TObjectView.DoMouseCommand 


(var TheMouse : Point; 
var Info : Eventlnfo; 

var Hysteresis : Point) : TCommand; override; 


SketcherCommand 
SelectorCommand 
DraggerCommand 
LensUnderMouse 

procedure CheckLens (Item : TLens); 
begin 

if PtlnRect (TheMouse, Item.Frame) then 
LensUnderMouse TItem; 


TSketcherCommand; 

TSelectorCommand; 

TDraggerCommand; 


DoMouseCommand gNoChanges; 
if fPaletteView.IsPointer then 

LensUnderMouse nil; 

fOpticsModel.EachLens(CheckLens); 
if LensUnderMouse - nil) then 
begin 

fOpticsModel.DeselectAll; 
new (SelectorCommand); 

SelectorCommand>ILensCommand (self, fOpticsModel, 
fDrawOpticalBench); 

DoMouseCommand SelectorCommand; 
else 

begin 

if not Info.TheShiftKey then 
fOpticsModel.DeselectAll; 

if (Info.TheShiftKey and LensUnderMouse.flsSelected) then 
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LensUnderMouse.Deselect 


LensUnderMouse.Select; 

if (fOpticsModel.NumberOfSelections > 0) then 
begin 

new (DraggerCommand); 

DraggerCommand.ILensCommand (self, fOpticsModel, 
fDrawOpticsBench); 

DraggerCommand.fConstrainsMouse 
fAutoGridEnabled; 

DoMouseCommand DraggerCommand; 


else** 

begin 

fOpticsModei.DeselectAll; 
new (SketcherCommand); 

SketcherCommand.lLensCommand (self, fOpticsModel, fDrawOpticalBench); 
SketcherCommand.fLens fPaletteView.CurrentTool; 
SketcherConimand.fLens.fOpticsModel fOpticsModel; 

SketcherCommand.fConstrainsMouse fAutoGridEnabled; 
DoMouseCommand SketcherCommand; 


Рассмотрим, как оптический объект отображения объединяется со своим 
объектом-палитрой. Объект-палитра знает только, как управлять выбором 
сервисной программы, но он не знает, что делать с таким выбором. Объект- 
палитра передает оптическому объекту отображения информацию о том, ка¬ 
кая сервисная программа выбрана. 

Как изображается объект-палитра? Можно использовать множество под¬ 
ходов, и самый простой из них — определить картинку, которую изобража¬ 
ет объект-палитра. Для того чтобы создать картинку, можно использовать 
любую программу, основанную на закрашивании пикселов (например, 
MacPaint), и затем вставить это изображение в ресурсный файл приложе¬ 
ния, используя такую сервисную программу, как ResEdit. Это опять тот 
случай, когда мы отделяем внешне наблюдаемые характеристики от исходно¬ 
го текста. В общем случае мы должны редактировать картинку много раз, 
пока ее вид не удовлетворит нашему представлению, но у нас имеется воз¬ 
можность сделать это без какой-либо перекомпиляции исходного текста и в 
конечном счете без воздействия на проект программы. 

Данное проектное решение приводит к следующему представлению 
класса: 


fCurrenlTool 

flmageRect 

fViewRect 


0 .. kKindsOfLenses; 
PicHandle; 

Rect; 

Rect; 


Последние три поля включают состояние картинки, как оно считывает¬ 
ся из ресурсного файла в ходе инициализации объекта-палитры. Таким об¬ 
разом, изображение палитры становится тривиальным: 

procedure TPaletteView.Draw (Area : Rect); 
begin 
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PenNormal; 

DrawPicture (flmage, flmageRect); 

MoveTo ((kPalettelmageWidth — 1), 0); 

LineTo ((kPalettelmageWidth — 1), kPalettelmageWidth); 


При нескольких вызовах к программам QuickDraw, мы сначала устанав¬ 
ливаем характеристики карандаша, выводим изображение картинки и затем 
рисуем линию, отделяющую палитру от просматриваемого объекта отображе¬ 
ния. Наблюдательный читатель увидит, что мы использовали константу 
kPalettelmageWidth при реализации метода DoMakeWindows, определенного 
для класса TOpticsDocument. Действительно, это классический пример того, 
почему мы объявляем константы вместо использования числовых литеров в 
нашей программе: константы помогают сделать нашу программу более по¬ 
нятной (а наши проектные решения более точными), а также более удобной 
для поддержки, увеличивая долю общих статических величин среди абст¬ 
ракций. 

При рассмотрении проекта данного класса интересной является функция 
CurrentTool. В нашем проекте CurrentTool возвращает объекту-линзе соот¬ 
ветствующую сервисную программу из палитры, выбранной в настоящий мо¬ 
мент. Оптический объект отображения затем использует данный объект в 
методе DoMouseCommand для инициализации выбора картинки сервисной 
программы объекта-команды. В нашей реализации CurrentTool можно ис¬ 
пользовать большой оператор выбора, оцениваемый для выбранного в насто¬ 
ящий момент элемента, и затем создавать соответствующую линзу. Но вы¬ 
полнение некоторого определенного для класса действия при простом рас¬ 
смотрении объекта класса приводит к некоторым противоречиям с объектно- 
ориентированным стилем: зачем проверять класс объекта, когда сам объект 
содержит эти знания? Вместо этого при нашем подходе создаются прототипы 
для каждой возможной линзы, когда начинается работа с приложением, а 
затем просто делаются копии линз, которые нам понадобятся. По этой при¬ 
чине мы объявляем массив PrototypeLenses в интерфейсе модуля 
UOpticsModels, который мы инициализируем таким образом, чтобы каждый 
элемент массива указывал на объект другого класса линз. Таким образом, 
данный массив формирует таблицу отображения сервисной программы на 
линзу. Его лучше всего определить в модуле UOpticsModels, но так как он 
должен быть видимым другим модулям, мы должны включить следующие 
объявления в интерфейс модуля: 


kKindsOfLenses - 6; 


PrototypeLenses : array[l .. kKindsOfbenses] of TLens; 
procedure InitializeOpticsModels; 

Общедоступная процедура InitializeOpticsModels аналогична процедуре 
InitializeOpticsDialogs, определенной в модуле UOpticsDialogs. 
InitializeOpticsModels вызывается из основной программы для создания и 
инициализации прототипа экземпляра каждой линзы, как показано в следу¬ 
ющем фрагменте: 
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DoubleConvexLens : TDoubleConvexLens; 

new (DoubleConvexLens); 

DoubleConvexLens.IShape (nil); 

ProlotypeLenses [kDoubleConvexLensID] DoubleConvexLens; 


Отметим, что мы опять предпочитаем использование таких констант, 
как KDoubleConvexLensID численным литерам. Выполняя реализацию метода 
CurrentTool, мы должны записать: 

function TPaletteView.CurrentTool : TLens; 
begin 

CurrentTool TLens (ProlotypeLenses [fCurrentTool] .Clone); 

end; 

Для того чтобы закончить с реализацией интерфейса пользователя, мы 
включаем диалоги, определенные в модуле UOpticsDialogs (рис. 9-16). Реа¬ 
лизация общедоступной процедуры DisplayDrawingSizeDialog приводит нас к 
введению некоторых проблемно-зависимых классов диалогов, которые вклю¬ 
чают желаемое поведение. Побочным действием данного рекурсивного проек¬ 
тирования является то, что мы заканчиваем проектирование, имея некото¬ 
рые мощные классы, которые мы могли бы использовать для других прило¬ 
жений. Другие диалоги, такие, как Lens Specification... (рис. 9-16), будут 
намного проще. Например, последний приводимый диалог сначала включает 
создание из шаблона соответствующего окна, затем установление начальных 
значений для каждого управления диалогом и в конце передачу управления 
пользователю (метод PoseModally) . Когда пользователь убирает диалог, уп¬ 
равление возвращается к методу, и формальные параметры функции уста¬ 
навливаются следующим образом: 

procedure DisplayLensSpecificationDialog (SelectedLens : TLens; 

var NewFocalLength : FocalLength; 
var AcceptChanges : Boolean); 

Window : TWindow; 

DialogView : TLensSpecificationDialogView; 

Dismisser : IDType; 

AString ; Str255; 

begin 

Window NewTemplate Window (kLensSpeciflcationResource, nil); 

DialogView TLensSpecificationDialogViewCWindow.FmdSubView <’DLOG’)>; 
DialogView.fPicture SelectedLens.fPicture; 

NumToString ((SelectedLens.fCenter.H — kOpticalBenchHOffset), AString); 
DialogView.ParamTxt ( ,Л 0\ AString); 

GetlndString (AString, kStringResource, SelectedLens. fName); 

DialogView.ParamTxt (’■'T, AString); 
if SelectedLens.fConverging then 

TNumberText (DialogView.FindSubView Cfocl’)).Minimum 0; 

TNumberText (DialogView.FindSubView (TocO).Maximum Maxlnt; 

end 

else 

begin 


Text (DialogView.FindSubView (’foci*)).Min 


iim Maxlnt; 
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TNumberText (DialogView.FindSubView (’foci’)).(Maximum 0; 

end; 

TNumberText (DialogView.FindSubView (’foci’)). 

SetValue (SelectedLens.fFocalLength, kDontRedraw); 

DialogView.SelectEditText (’foci’. True); 

Dismisser DialogView.PoseModally; 

if (Dismisser - ’ok ’) then 

NewFocalLength 

Focaltength(TNumberText (DialogView.FindSubView (’focl’H.GetValue); 

AcceptChanges (Dismisser - ’ok ’) and 

(NewFocalLength <> SelectedLens.fFocalLength); 

Window.Close; 

end; 

Для того чтобы иметь законченную, выполняемую программу, мы долж¬ 
ны создать основную программу. Создание основной программы как послед¬ 
него действия по реализации кажется невероятно странным для тех, кто 
придерживается методов структурного проектирования. Однако в объектно- 
ориентированных системах корень системы для нас не особенно важен; нас 
интересует прежде всего, как найти место для объектов самого высокого 
уровня. Итак, для инструментального средства разработки конструкций гео¬ 
метрической оптики мы можем написать основную программу MOptics следу¬ 
ющим образом: 
programm Optics; 


UMacApp, UPrinting, UDialog, UTeView, 

UOpticsModels, UOpticsDialog, UOpticsControllers, UOpticsViews, 
UOpticsDocunent, UOptics; 

{$S Main} 

gOpticsApplication : TOpticsApplication; 


begin 

InitUMacApp (10); 

InitPrinting; 

InitializeOpticsModels; 

InitializeOpticsDialogs; 

InitializeOpticsViews; 

new (gOpticsApplication); 

gOpticsApplication.IOpticsApplication; 

gOpticsApplication.Run; 


Теперь мы можем создать исполняемый прототип для отработки наибо¬ 
лее важных элементов интерфейса пользователя. Мы полностью поддержива¬ 
ем данную раннюю интеграцию, для того чтобы мы могли обнаружить лю¬ 
бой серьезный недостаток в интерпретации требований или в выборе меха¬ 
низмов. 

Реализация модели 

Если нас удовлетворяет интерфейс пользователя, мы можем завершить 
проектирование и реализацию классов, содержащихся в модулях 
UOpticsControllers и UOpticsModels. Действительно, если мы имеем достаточ¬ 
но ресурсов разработки, можно развивать интерфейс пользователя и его глу¬ 
бинную модель параллельно. 
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Реализация подклассов класса TShape. Сначала выберем представление 
для класса TLens. Мы используем подход, подобный тому, который мы при¬ 
меняли для класса TPaletteView. Таким образом, мы будем создавать кар¬ 
тинку для каждой линзы (поэтому их можно легко изменять), и метод 
Draw будет реализовывать изображение этой картинки. Кроме полей, требу¬ 
емых для содержания ресурсов данной картинки, нам необходимо дополни¬ 
тельное состояние. В частности, мы должны поддерживать простую иденти¬ 
фикацию класса линз для того, чтобы использовать ее, когда происходит 
считывание и запись состояния документа. Так как Object Pascal не поддер¬ 
живает устойчивость объекта, мы должны свертывать его путем кодирования 
класса каждого объекта в файл данных документа. Необходимо также по¬ 
мнить текущее и последнее положение линзы, и выбрана ли она в настоя¬ 
щий момент. Наконец, мы должны помнить фюкусное расстояние линзы, яв¬ 
ляется ли она собирающей или рассеивающей (что влияет на допустимый 
диапазон значений ее фокусного расстояния), и ее научное название (так, 
чтобы мы могли изобразить ее в Lens Specification... диалоге). Получив эти 
параметры, мы можем завершить реализацию интерфейса класса TLens сле¬ 
дующим образом: 


пц 

fCenter 

fDraggingCenter 

fEtenlRect 

nsSelected 

fPicture 

fFocalLength 

fConverging 


Integer; 

Point; 

Point; 

Reel; 

Boolean; 

PicHandle; 

Integer; 


Так как TLens представляет в нашей проблеме наиболее низкий уро¬ 
вень абстракции, его реализация завершается выполнением значительного 
объема работы. Например, считыванием и записью документа управляет объ¬ 
ект-приложение, но знанием о том, как считать и записать индивидуальный 
объект-линзу, обладает только сам объект-линза. Таким образом, мы можем 
реализовать методы DoRead и DoWrite объекта линзы, которые должны до¬ 
полнять друг друга: 


procedure TLens.DoRead (ARefNum : Integer); 

Size : Longlnt; 

TheCenter : Point; 

TheFocalLenglh : FocalLength; 

begin 

Size SizeOf (Point); 

FailOSErr (FSRead (ARefNum, Size, @TheCenter)); 
fCenter - TheCenter; 

Size SizeOf (FocalLength); 

FailOSErr (FSRead (ARefNum, Size, @TheFocalLength)); 
fFocalLength TheFocalLenglh; 


procedure TLens.DoWhile (ARefNum : Integer); 
var 

TheLensData 
Size 
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: LensData; 
: Longlnt; 
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begin 

TheLensData.Theld fid; 

TheLensData.TheCenter fCenter; 
TheLensData.TheFocalLength fFocalLength; 

Size SizeOf (LensData); 

FailOSErr (FSWrite (ARefNum, Size, @TheLensData)); 

end; 


Данные методы не вызываются непосредственно объектом-приложением; 
они вызываются объектом оптическая модель, которому принадлежат линзы. 
Например, метод DoRead класса TOpticsModel представлен следующим обра¬ 
зом: 

procedure TOpticsModel.DoRead (ARefNum : Integer); 

Size : Longlnt; 

Count : Integer; 

ThelD : Integer; 

ALens : TLens; 

Index : Integer; 

begin 

Size SizeOf (Integer); 

FailOSErr (FSRead (ARefNum, Size, @Count)>; 
for Index 1 to Count do 
begin 

Size SizeOf (Integer); 

FailOSErr (FSRead (ARefNum, Size, @TheId)); 

ALens TIens (PrototypeLenscs [Theld] .Close); 

ALens.fOpticsModel self; 

ALens.DoRead (ARefNum); 
fLenses.Insentens 

TraceRays; 


Обратите внимание, что данный метод использует тот же массив 
PrototypeLenses, который мы использовали в классе TPalletteView. После 
того как модель была считана с диска, самым последним действием являет¬ 
ся процесс вычерчивания луча; короче говоря, мы придем обратно к данно¬ 
му методу. 

Реализация команд. Так как мы завершили реализацию методов раз¬ 
личных объектов-линз и объектов оптических моделей, которые нужны для 
механизма отображения МасАрр, мы можем завершить реализацию классов 
команд. Например, рассмотрим класс TSketcherCommand, который отвечает 
за размещение новой линзы на оптической скамье и за перемещение мыши, 
пока пользователь передвигает линзу в ее положение. Данный класс являет¬ 
ся подклассом TLensCommand и добавляет одно поле fLens к состоянию его 
объектов. Объект-команда «картинка» сервисной программы создается при 
вызове метода DoMouseCommand, определенного в классе TOpticsView. Ини¬ 
циализация объекта-команды «картинка» сервисной программы является про¬ 
стой: сначала мы вызываем метод его суперкласса (который инициализирует 
поля, определенные в его суперклассе), следующим инициализируется объ¬ 
ект-команда с текущим состоянием МасАрр, и в конце инициализируется 
локальное поле fLens. Мы можем выразить это следующим образом: 

procedure TSketcherCommand.ILensCommand (ASuperView : TView; 

AnOptirsModcl : TOplicsModcl; 
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DrawPosition : Boolean); override; 

begin 

inherited ILensCommand (ASuperView, AnOpticsModel, DrawPosition); 
ICommand (kSketcherCommand, ASuperView.fSuperViewf.SuperView.fDocument, 
ASuperView, TScroller (ASuperView.fSuperView)); 
fLens nil; 


В классе TCommand существует поле fChanges, которое инициализиру¬ 
ется True командой ICommand. Когда объект-приложение выполняет коман¬ 
ду, он увеличивает счетчик изменений соответствующего объекта-документа 
(поле fChangeCount), только если поле fChanges содержит True. Вспомним 
из предыдущей дискуссии по поводу механизма документов МасАрр, что 
МасАрр проверяет поле fChangeCount объекта-доку мента, прежде чем за¬ 
крыть его, для того чтобы дать пользователю возможность сохранить любые 
изменения. Это будет именно то, что нам следует ожидать. Такие действия, 
как выбор картинки сервисной программы, вырезание, вставка, перемещение 
изменяют состояние объекта-документа, и мы не хотим, чтобы пользователь 
по невнимательности потерял такие изменения. Здесь мы имеем еще один 
пример, как система может показывать очень сложное поведение с помощью 
некоторых очень простых механизмов. 

Как мы видим, в реализации метода DoMouseCommand, определенного 
в классе TOpticsView, после того как оптический объект отображения созда¬ 
ет объект-команду «картинку» сервисной программы, объект отображения 
инициализирует поле flins картинки сервисной программы объектом, на ко¬ 
торый указывает текущая сервисная программа палитры. В нашей реализа¬ 
ции метода CurrentTole fLens, таким образом, указывает на имитацию про¬ 
тотипа линзы. 

Метод Dolt выполняется объектами класса TSketcherCommand там, где 
получается реальное действие. По существу мы должны вставить новую 
линзу в оптическую модель, пометить ее как выбранную и затем получить 
новый путь луча. Мы можем выразить данный алгоритм следующим обра¬ 
зом: 

procedure TSketchcrCommand.DoIt; override; 

fOpticsModel.AddLens (fLens); 

fLens.Selcct; 

fOpticsModel.TraceRays; 


Undolt и Redolt вызываются объектом-приложением согласно управле¬ 
нию МасАрр командой Undo в Edit -меню. Действие Undolt заключается в 
простом обращении действия Dolt, а действие Redolt заключается в обраще¬ 
нии действия Undolt. Таким образом, мы можем написать: 

procedure TSketcherCommand.UndoIt; override; 
begin 

if fVicw.Focus then 
begin 

fOpticsModel.DeselectAII; 
fOpticsModci.RemoveLens (fLens); 
fOpticsModel.TraceRays; 

procedure TSketcherCommand.RedoIt; override; 



324 


Применения 


begin 

if fView.Focus then 
begin 

fOpticsModel.DeselectAll; 

Dolt; 


MacApp определяет состоящий из двух частей процесс для выполнения 
команды. До того как метод HandleEvent объекта-приложения выполняет но¬ 
вую команду (через метод Dolt), HandleEvent сначала передает последнюю 
команду (через вызов метода Commit). Объект-команда может быть создан и 
затем отменен, и поэтому он никогда не передается. В любом случае перед 
попыткой выполнить новую команду, МасАрр освобождает последнюю коман¬ 
ду так, что старые объекты-команды не накапливаются во времени. Таким 
же способом объект-команда может использовать медленную эволюцию; это 
означает, что он сможет передать методу Commit часть своей работы, кото¬ 
рую будет сложно или невозможно отменить или выполнить снова, напри¬ 
мер такую, как изменение состояния очень большого документа. Когда ко¬ 
манда-картинка сервисной программы выполнена (через метод Dolt), объект, 
на который указывает поле fLens, представляет собой два совместно исполь¬ 
зуемых объекта: сам объект-команда «картинка» сервисной программы и объ¬ 
ект оптическая модель. Если команда-картинка сервисной программы отмене¬ 
на, то, когда мы освобождаем объект-команду, мы также должны освободить 
линзу, на которую указывает поле fLens. Таким образом, мы должны на¬ 
писать: 

procedure TSketcherCommand.Free; override; 
begin 

FreeObject (fLens); 

inherited Free; 


FreeObject является подпрограммой, определенной в МасАрр. В этой 
подпрограмме сначала проверяется, равно ли нулю значение числа ссылок 
на данный объект, а если нет, вызвать его метод Free. 

Когда команда-картинка сервисной программы передана, объект-команда 
должен прервать его связь с объектом-линзой, так чтобы, при освобождении 
команды, мы не разрушили линзу. Поэтому был использован предшествую¬ 
щий вызов подпрограммы FreeObject. Таким образом, метод Commit можно 
завершить следующим образом: 

procedure TSketcherCommand.Commit; override; 
fLens nil; 


Объект-команда «картинка» сервисной программы должна выполнять еще 
две важные функции: она должна соответствующим образом перемещать 
мышь, когда пользователь перемещает линзу в определенное место, а также 
обеспечивать некоторые визуальные подсказки, чтобы пользователь мог ска¬ 
зать, где именно объект располагается на оптической скамье. Как часть 
процесса обработки, включенная в управление нажатием клавиши мыши, 
объект-приложение предоставляет текущей команде возможность перемещать 
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мышь, вызывая его собственный метод TrackMouse. При перемещении мыши 
объект-приложение повторно вызывает метод TrackFeedback объекта, который 
управляет перемещением мыши (он обычно является объектом-командой). 
Таким образом, эти два метода должны работать совместно, чтобы создать у 
пользователя иллюзию, что он сам перемещает линзу по экрану. 

Действие мыши состоит из трех частей: нажатие клавиши мыши, пере¬ 
движение мыши, отжатие клавиши мыши. Большинство команд могут игно¬ 
рировать отжатие клавиши мыши (исключение составляют некоторые коман¬ 
ды, которые должны рисовать объекты, состоящие из множества частей, 
например, многоугольники). Когда обнаружено нажатие клавиши мыши, ме¬ 
тод TrackMouse заставляет обновляться объект отображения и новая линза 
появляется впервые. Таким образом, при движении мыши метод TrackMouse 
восстанавливает область под мышью. Затем метод TrackFeedback изображает 
линзу снова, но в другом месте. Концептуально можно представить метод 
TrackMouse как процесс, который убирает линзу, а метод TrackFeedback как 
процесс, который изображает новую линзу. Так как МасАрр повторяет дан¬ 
ный процесс как часть механизма главного цикла событий, то пользователю 
кажется, что объект начинает медленно перемещаться по экрану. Мерцание 
обычно обнаруживается, когда рисование объекта занимает много времени. 
Это объясняет существование метода TrackFeedback. Обычно, когда переме¬ 
щается объект, пользователю не нужно видеть объект целиком, а только 
каркас основных его частей. В нашем приложении мы можем целиком рисо¬ 
вать линзу, потому что вывод единственной картинки на экран не требует 
значительных ресурсов компьютера. 

Теперь мы можем завершить реализацию двух методов класса 
TSketcherCommand: 

procedure TSkelcherCommand.TraceFeedback (AnchorPoint, 

NexlPoinl : VPoint; 

TumltOn, 

MouseDidMove : Boolean); override; 


APoint : Point; 

if MouseDidMove then 
begin 

PenMode (PatOR); 

APoint VPtToPt (NextPoint); 

APoint.V kOpticsAxis; 

APoint.H Max (APoint.H, 

(kOpticalBenchHOffset + kMinimumHOffset)); 

APoint.H Min (APoint.H, 

(fView.fSize.H — kOpticalBenchHOffset 
— kMinimumHOffset)); 

fLens.fCenter APoint; 
fLens.DrawLens (fDrawPosition); 

function TSketcherCommand.TraceMouse (ATrackPhase : TrackPhase; 

var AnchorPoint, 

PreviousPoint, 

NextPoint : VPoint; 

MouseDidMove : Boolean); TCommand; override; 
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TrackMouse self; 
if (ATrackPhase - TrackPhase) then 
begin 

fView.GetWindow.Update; 
if fView.Focus then; 

end; 

else if ((ATrackPhase - TrackMove) and MouseDidMovc) then 
begin 

fLens.Invalidate; 
fView.GetWindow.Update; 
if fView.Focus then; 



В теле метода TrackFeedback мы должны убедиться, что линза не пере¬ 
мещается за пределы оптической скамьи и всегда располагается вдоль опти¬ 
ческой оси (горизонтальной линии, обозначаемой константой kOpticalAxis) . 

Так как требования предусматривают, чтобы пользователь мог ограни¬ 
чивать перемещение мыши метками шкалы, расстояние между которыми 
равняется пяти точкам (через Enable Autogrid команду меню), все команды 
должны выполнять метод TrackConstrain. Таким образом, предполагая, что 
можно ограничивать перемещения мыши, до того как вызываются методы, 
как TrackMouse и TrackFeedback, МасАрр сначала вызывает метод 
TrackConstrain, чтобы позволить объекту ограничить перемещение мыши оп¬ 
ределенной областью или определенным дискретом перемещения. Все коман¬ 
ды должны совместно использовать данное поведение, поэтому мы ввели 
класс TLensCommand, в котором реализация метода TrackContrain использу¬ 
ется всеми объектами-командами: 

procedure TLensCommand.TrackConstrain (AnchorPoint, 

PreviousPoint : VPoint; 

var NextPoint : VPoint); override; 

begin 

NcxtPoint.il (NextPoint.H div kAutoGridSize) * kAutoGridSize; 

NextPoinl.V (NextPoint.V div kAutoGridSize) * kAutoGridSize; 


Механизм буфера МасАрр связан с обработкой команд. В стандарте ин¬ 
терфейса пользователя Macintosh предполагается, что все приложения по 
возможности поддерживают общие команды редактирования: вырезание, ко¬ 
пирование, чистку и вставку. Требования в нашей задаче также опрсдсляют 
данное поведение, и это объясняет, почему мы имеем специализированные 
классы TCutCommand, TCopyCommand, TClearCommand, TPasteCommand. 

Когда создается объект-команда «вырезать» (в методе DoMenuCommand 
оптического объекта отображения), мы инициализируем его, используя все 
линзы, выбранные в настоящий момент в объекте отображения. Когда мы 
выполняем данную команду, в результате ее действия линзы убираются из 
оптической модели, появляется новый путь луча, и затем все линзы сохра¬ 
няются так, что они могут быть вставлены в этот или другой объект ото¬ 
бражения. Команда «копирование» выполняет подобное действие помимо то¬ 
го, что она копирует линзы, но она не убирает их из модели. Команда 
«очистить» только убирает выбранные линзы из модели; она не копирует 
их. Когда создается команда «вставить» (которая возможна только тогда, 
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когда имеется что вставить), она «заглядывает» в то же место, где послед¬ 
няя команда «копировать» или «вырезать» сохранила свое состояние. 

Общее хранилище -вырезанных и скопированных объектов называется 
буфером, и каждое приложение обычно имеет только один буфер. В основ¬ 
ном буфер подобен любому объекту отображения, хотя пользователь не мо¬ 
жет его редактировать, но может его просматривать (с помощью 
ShowBuffer). Мы должны поддерживать список объектов, которые были выре¬ 
заны или скопированы и, следовательно, могут быть вставлены. Это озна¬ 
чает, что буфер должен иметь возможность обрабатывать простые объекты, 
такие, как текст, или более проблемно-зависимые, такие, как линзы. Буфер 
также позволяет копировать или вставлять объекты в другие приложения. 
Например, мы можем вырезать линзы из инструментального средства разра¬ 
ботки конструкций геометрической оптики и вставить его в приложение для 
рисования; фактически так создано большинство рисунков в данной главе. 

Так как буфер должен обрабатывать объекты проблемно-зависимых 
классов, мы должны включить удобный класс TClipboardView в наше прило¬ 
жение. Но поскольку он аналогичен классу TOpticsView, мы не будем 
рассматривать реализацию и использование. 

Применение алгоритмической декомпозиции. Предполагая, что мы за¬ 
кончили реализацию команд всех классов, мы остановимся на одном методе, 
с которого все проектировщики должны будут начинать: методе TraceRays, 
определенном в классе TOpticModel. Почему мы выбрали данный метод? По- 
видимому, он потребует большого объема математических вычислений, необ¬ 
ходимых для данного приложения. Это действительно так, но наши концеп¬ 
туальные принципы для всех объектно-ориентированных систем состоят в 
том, что мы рассматриваем мир как объединение объектов, которые соединя¬ 
ются друг с другом для достижения желаемой функциональности. Управле¬ 
ние, основной центр структурного проектирования, не является наиболее 
важной для нас целью. 

На данном этапе, когда мы имеем все ключевые абстракции, мы 
можем воспользоваться методом TraceRays. Если мы предполагали, что дан¬ 
ный алгоритм имеет высокий процент риска, мы должны были параллельно 
с нашими разработками привлечь к работе физиков для прототипирования 
алгоритма. Но оказалось, что алгоритм данного метода достаточно прост; 
при условии что известны основные механизмы, которые мы уже ввели. 

По законам геометрической оптики луч начинается от реального объек¬ 
та, затем проходит от линзы к линзе в порядке увеличения их расстояния 
от действительного объекта. Это объясняет, почему мы сохраняли состояния 
линз в оптической модели, используя список fLcnscs, который является по¬ 
лем класса TLcnsList. Класс TLensList является подклассом класса 
TSortedList, поэтому когда мы вставляем линзы в оптическую модель, они 
располагаются в порядке, соответствующем их положению вдоль оптической 
скамьи. Таким образом, при реализации метода TraceRays мы сначала дол¬ 
жны разрушить все существующие образы и лучи, а затем повторить все 
заново, используя список линз модели. Кроме того, мы должны сделать не¬ 
действительным весь объект отображения, потому что мы полностью измени¬ 
ли его изображение: 

procedure TOpticsModel.TraceRays; 

Image : TImage; 

procedure Processions (Item : TLens); 



328 


Применения 


flmages.FreeAll; 
fRays FreeAll; 

Image IRealObject; 

EachLens (ProcessLens); 
if (fView <> nil) then 
begin 

fView.GetWindow.ForceRedraw; 
if fViSw.Focus then; 




Так как мы разложили алгоритм на небольшие части, локально вло¬ 
женная процедура ProcessLens выполняет только небольшую часть работы. 
Она должна создать основные лучи, которые проходят от источника через 
линзы, и затем создать объект отображения в точке пересечения лучей. Ес¬ 
ли данная точка находится с той же стороны линзы, что и источник изо¬ 
бражения, мы имеем мнимое изображение; если она находится с другой 
стороны линзы, мы имеем действительное изображение. Выше мы спроекти¬ 
ровали класс TRealOrVirtuallmage, чтобы действительное и мнимое изобра¬ 
жения рисовались по-разному согласно их позиции. Таким образом, мы мо¬ 
жем завершить вложенную процедуру следующим образом: 

procedure ProcessLens (Item ; TLens); 

Lens : TLens; 

Rays : TRays; 

RealOrVirtuallmage: IRealOrVirtuallmage; 

begin 

Lens Item; 

if (Lens.fFocalLength <> 0) then 
begin 

new (Rays); 

Rays.IShape (self); 

Rays.SetPoint (Image, Lens); 
fRays.InsertFirst (Rays); 
new (RealOrVirtuallmage); 

RealOrVirtuallmage.IShape (self); 

RealOrVirtuallmage.SetPosition (Rays.ImageAt, Lens); 
flmage.InserlFlrst (RealOrVirtuallmage); 

Image RealOrVirtuallmage; 



Рассмотрим теперь класс TRays, так как именно здесь осуществляется 
реальное действие. Метод SetPoint должен определить точку прохождения 
лучей через фокус. Для этого мы должны обработать только два из трех 
основных лучей, так как в евклидовой геометрии две непараллельные линии 
в одной плоскости пересекаются в точке. Наиболее простой луч — луч, ко¬ 
торый проходит без изменения от источника через центр линзы, и другой 
простой луч — луч, который параллелен оптической оси и преломляется по 
направлению к точке фокуса. 

Профессиональный программист, вероятно, уже должен был бы вовсю 
писать исходные тексты программ, но прервемся на момент и посмотрим на 
данную проблему с точки зрения объектно-ориентированной перспективы. 
Имеются ли какие-нибудь классы или объекты, которые интересуют нас 
здесь? Ответом будет «да»! Мы объяснили наш алгоритм в терминах линий, 
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и, таким образом, имеет смысл ввести класс, который отражает данный 
взгляд на мир. 

Мы можем проще всего определить пересечение двух лучей, если знаем 
уравнения линий, а уравнение каждой линии может быть задано двумя точ¬ 
ками. Это позволяет иметь несколько операций над объектами-линиями, ко¬ 
торые могут быть выражены в объявлении класса следующим образом: 

типе - object (TObject) 

fSlope : Real; 
fDelta : Real; 

procedure TUne.IUne (Pointl, Point2 : Point); 

function TUne.Y (X : Real) : Real); 

function TUne.Intersection (AUne : TUne) : Point; 




Операции Шпе и Intersection выполняются так, как это подсказывают 
их имена. Функция Y, имея параметром координату X, возвращает соответ¬ 
ствующее значение вдоль оси Y согласно уравнению линии. 

Мы можем поместить данный класс и его реализацию в тело модуля 
UOpticsModels потому, что нет необходимости в том, чтобы он был види¬ 
мым другим классам или объектам в системе. После того как мы уже по¬ 
строили интерфейс данного класса, это легко завершить, используя 
евклидову геометрию: 

procedure TUne.IUne (Pointl, Point2 : Point); 
begin 

fSlope (Pointl.V — Polnt2.V) / (Pointl.H — Point2.H); 

fDelta (Pointl.V * 1.0) — (Pointl.H • fSlope); 

end; 

function TUne.Y (X : Real) : Real); 
begin 

Y (fSlope • X) + fDelta; 

end; 

function TUne.Intersection (AUne : TUne) : Point; 

X : Real; 

APoint : Point; 

begin 

if (fSlope - AUne.fSlope) then 
SetPt (APoint, 0, 0) 
else 

begin 

X (AUne.fDetta — fDelta) / (fSlope — AUne.fSlope); 

APoint.H trunc(X); 

APoint. V trunc(Y(X)); 

Intersection APoint; 
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Рис. 9-17. Инструментальное средство разработки конструкций 
геометрической оптики. 

Завершение метода SetPoint для класса TRays становится почти триви¬ 
альным: мы создаем линии для двух основных лучей и затем определяем их 
пересечение: 

procedure TRays.SetPoint (FromTmage : Tlmage; ThroughLens : TLens); 

FirstLine : TLine; 

SecondLine : TLine; 

APoint : Point; 

SecondFocalPoint : Point; 

begin 

fFromlmagc Fromltnage; 

(Through l.cns ThroughLens; 

fLensCcntcr fThroughLens.fCenter; 
new (FirsiLinc); 

FirstLine.ILine (IFrotnlmage.fTop, fThroughLens.fCenter); 

SetPt (APoint, 

fThroughLens.fCenter.H, fFromlmage.fTop.V); 

SetPt (SecondFocalPoint, 

fThroughLens.fCenter.H + fThroughLens.fFocalLength), kOpticalAxis); 
new (SecondLine); 

SecondLine.lLine (APoint, SecondFocalPoint); 
fToPoint FirstLine.Intersection (SecondLine); 


Таким образом объектно-ориентированное проектирование является ре¬ 
курсивным процессом. На примере класса TLine видно, как, углубляясь в 
реализацию, мы часто обнаруживаем новые обобщенные классы, которые 
имеют слабую связь со словарем предметной области, но представляют важ¬ 
ные элементы механизмов, в которых мы нуждаемся для удовлетворения 
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функциональных требований. Одно важное достоинство данного рекурсивного 
процесса заключается в том, что мы часто завершаем разработку созданием 
классов, которые можно использовать в других приложениях; таким образом, 
объединение программных компонент многократного использования 
расширяется со временем. 

Итак, реализация инструментального средства разработки конструкций 
геометрической оптики на данном этапе завершена. На рис. 9-17 показан 
снимок экрана рабочей версии приложения. 

9.4. МОДИФИКАЦИЯ 
Добавление новых возможностей 

Отличительной чертой хорошо структурированной сложной системы яв¬ 
ляется восприимчивость к изменениям. Ниже рассмотрены три 
функциональных усовершенствования инструментального средства разработки 
конструкций геометрической оптики и показано, как проект реагирует на 
эти изменения. 

Первое усовершенствование касается производительности метода 
TraceRays. Можно увеличить скорость работы? Мы могли бы использовать 
гистограммные сервисные программы, которые указывают на программы, 
требующие для своего выполнения наибольшего времени. Из наблюдений за 
работающей системой следует, что программа тратит много времени на пе¬ 
рерисовку оптического объекта отображения после прохождения луча. Это не 
считается чем-то необычным, так как операции рисования довольно слож¬ 
ные. Тем не менее, если мы вернемся к реализации метода TraceRays, мы 
увидим, что код исходного текста объекта отображения заставляет перерисо¬ 
вывать его целиком, даже если только часть объекта отображения подверга¬ 
ется воздействию. Поэтому одно очевидное усовершенствование заключается 
в оптимизации процесса изображения путем перерисовывания только тех об¬ 
ластей объекта отображения, которые изменяются. 

Это означает, что мы должны только слегка изменить реализацию ме¬ 
тода TraceRays. Для этого сначала, прежде чем освободить изображение или 
луч, мы должны сообщить каждому объекту, чтобы он сделался недействи¬ 
тельным. Затем вложенная процедура ProcessLens делает недействительными 
новые объекты: изображение и луч сразу после того, как они созданы и 
инициализированы. И наконец, мы можем убрать вызов метода ForceRedraw, 
так как другие изменения гарантированно аккумулируют области, включаю¬ 
щие только измененные части объекта отображения, и эти изменения за¬ 
ставляют объект отображения производить новый проход луча не так резко, 
как другим способом. Итак, используя наши механизмы мы могли повысить 
производительность системы, оптимизируя только ключевую абстракцию. Бо¬ 
лее того, в начале разработки нашего проекта мы не задавались вопросами 
производительности, но предполагали, что эти вопросы будет легче решить 
после того, как мы будем иметь основу структуры системы, которую можно 
использовать в дальнейшем. 

Предположим, мы убедили автора требований, что ограничения на при¬ 
ложение, связанные с использованием более четырех документов одновремен¬ 
но, были довольно произвольными. Для того чтобы ослабить эти ограниче¬ 
ния, нам надо только изменить реализацию метода TOpticsDocumentManager. 
В частности, надо изменить представление класса, чтобы использовать спи¬ 
сок, а не массив документов. Затем, надо модифицировать несколько мето- 
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дов, чтобы использовать данный список вместо массива. И наконец, мы дол¬ 
жны изменить ресурс, который определяет Experiments -меню, так чтобы ме¬ 
неджер оптического документа мог добавлять или убирать элементы меню. 

Поэтому здесь мы внесли изменения в требования, которые упрощают 
использование данного приложения. Внесение данного изменения требует мо¬ 
дификации не одного метода; но поскольку мы использовали только один 
класс для инкапсуляции -всего поведения, необходимого для управления мно¬ 
жеством документов, и затем представляли только абстрактное поведение 
класса, данное изменение не воздействует на семантику любого другого 
класса. Нам надо выполнить рекомпиляцию некоторых программных модулей 
высокого уровня, но данное изменение не уменьшит нашу уверенность в 
корректности всех других классов. 

Рассмотрим еще одно усовершенствование. Предположим, что на ранней 
стадии разработки от пользователей получен сигнал, что они хотят иметь 
на экране изображение точки фокуса линзы и данный атрибут должен пере¬ 
ключиться подобно тому, как это выполняет команда меню ShowGridLines. 
Данное требование приводит к необходимости изменить реализацию более 
чем одного класса. 

Начиная с самого нижнего программного модуля в нашем проекте, мы 
должны добавить новый параметр в методы DrawLens и Draw в классе 
TLens, указывающий, должна ли точка фокуса изображаться на экране. 
Данный параметр подобен существующему параметру DrawPosition. Мы дол¬ 
жны внести подобные изменения в метод Draw класса TOpticalBench. Состо¬ 
яние данной команды переключения будет содержаться в объекте отображе¬ 
ния так же, как и поле fDrawPageBreaks. В классе TOpticsView мы должны 
модифицировать метод Draw для использования дацного нового поля. Нам 
также надо модифицировать методы DoSetUpMenus и DoMenuCommand в 
классе TOpticsView для обработки данной новой команды. Наконец, мы дол¬ 
жны добавить данный элемент меню в наш ресурсный файл. 

Внимательный читатель обнаружит, что мы внесли три различных типа 
изменений в наш существующий проект и эти изменения типичны для объ¬ 
ектно-ориентированных систем. В первом случае мы модифицировали реали¬ 
зацию единственного метода, во втором — реализацию единственного клас¬ 
са, в третьем — интерфейсы и реализацию нескольких классов. Во всех 
этих классах изменения являются совместимыми. Другими словами, мы мо¬ 
жем простыми средствами дополнить наши существующие механизмы и ин¬ 
терфейсы, для того чтобы изменить поведение системы. Нам не пришлось 
изобретать какие-либо новые механизмы или изменять основную семантику 
каких-либо ключевых абстракций. Мы убеждены, что наш проект инстру¬ 
ментального средства разработки конструкций геометрической оптики являет¬ 
ся гибким; он может легко совмещать множество изменений в проблемной 
области. 

Изменение требований 

Скептически настроенный читатель может сказать, что мы выбирали 
только те изменения, которые легко реализовать. Рассмотрим изменение 
основных требований и посмотрим, как это повлияет на наш проект. 

В ходе работы мы имеем дело только с частью проблем геометрической 
оптики — с явлениями преломления. Что произойдет, если мы включим в 
нашу проблемную область явления отражения? Это означает, что наше при¬ 
ложение должно было бы оперировать не только линзами, но и зеркалами. 
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Для того чтобы сделать нашу проблему более интересной, рассмотрим как 
плоские поверхности, так и сферические. Рассмотрим эти изменения снизу 
вверх. Анализ проблемы указывает на то, что мы должны согласовать три 
новых типа объектов: плоские, поверхности, выпуклые поверхности. Очевид¬ 
ным местом для размещения этих классов является программный модуль 
UOpticsModels; мы должны так модифицировать реализацию класса 
TOpticsModel, чтобы он содержал эти линзы как часть его состояния. Для 
этого мы спроектировали бы класс ТМігтог так, чтобы он имел те же су¬ 
перклассы, что и класс TLens. 

Что можно сказать о методе TraceRays? Существующий класс TRays не 
окажет действительной помощи, потому что он только содержит информа¬ 
цию об основных лучах, которые проходят через линзу. Тем не менее мы 
можем использовать его как образец, и мы можем, несомненно, рассчиты¬ 
вать на класс TLine. Таким образом, наша стратегия заключалась бы в ре¬ 
организации структуры классов; в результате появятся два класса: 
TLensPrincipleRays и TMirrorPrincipleRays, которые являются подклассами 
класса TPrincipleRays. Из-за явного разделения понятий среди этих абстрак¬ 
ций реализация данных классов не является сложной — только немного 
утомительной. 

Двигаясь вверх по архитектуре модулей, нам необходимо было бы сде¬ 
лать полезные изменения в различных классах объектов-команд. Действи¬ 
тельно, логика существования классов команд такова, что объекты-команды 
мало заботятся об объектах, которыми они управляют. Итак, общее поведе¬ 
ние линз и зеркал может быть собрано в общий подкласс, и затем мы мо¬ 
жем определить все классы команд так, чтобы они основывались на данном 
общем классе. Это является примером сильных свойств полиморфизма. 

Если мы будем перемещаться вверх по иерархии к программным моду¬ 
лям более высокого уровня, то изменения становятся менее существенными. 
Мы должны добавить несколько новых диалогов и новых команд (таких, 
как Show Mirror Specification...), но в других случаях классы объектов ото¬ 
бражения, документов и приложения, которые мы уже определили, не зави¬ 
сят от изменений и расширений в классах нижнего уровня. 

Новые требования на отражающие поверхности действительно приводят 
к изменениям в нашей существующей реализации. Но никакие из этих из¬ 
менений не разрушают структуры нашего проекта. 

Дополнительная литература 

Фундаментальные основы геометрической оптики изложены Sears, 
Zemansky и Young [I, 1987). В работе Foley и van Dam [С, 1982] обсужда¬ 
ется применение принципов геометрической оптики для алгоритмов прохож¬ 
дения лучей в компьютерной графике. Библиотека классов МасАрр для 
Object Pascal описана в МасАрр [С, 1989]. Schmucker [С, 1986] представля¬ 
ет введение в МасАрр. Обобщения по языку программирования Object Pascal 
и примеры представлены в приложении. В библиографии предлагается не¬ 
сколько ссылок на различные системы, основанные на окнах, и объектно- 
ориентированные интерфейсы пользователя (см. раздел К, «Tools and 
Environments»). 



Глава 10 


C++. Система регистрации ошибок в 
программных средствах 

Для большинства коммерческих приложений фирмы предпочитают ис¬ 
пользовать готовые системы управления базами данных (СУБД), гарантиру¬ 
ющие реализацию параллельного доступа к данным, интеграцию, защиту и 
восстановление данных. Но любая СУБД требует обеспечения адаптации к 
задачам конкретного предприятия, поэтому в большинстве случаев создание 
подобных систем осуществляется в два этапа: 

1) проектирование структуры базы данных экспертами по СУБД; 

2) проектирование программных процессов обработки данных специалистами 
в прикладной области. 

Такой подход имеет определенные достоинства, но оставляет нерешен¬ 
ными некоторые важнейшие вопросы. Между проектировщиками СУБД и 
программистами существуют принципиальные расхождения, связанные с раз¬ 
личием методологий и приемов работы. 

Проектировщикам СУБД свойственно смотреть на мир как на совокуп¬ 
ность устойчивых и монолитных таблиц данных, а программисты видят мир 
в форме потоков управления. Пока невозможно рассчитывать на достижение 
единого интегрированного подхода к проектированию сложных систем. Если 
в системе преобладает проблема обработки данных, мы должны быть готовы 
к достижению компромисса в логике СУБД без учета особенностей задачи 
одинаково неэффективно и бессмысленно. Аналогично решение прикладной 
задачи без учета требований СУБД приводит к неразумным требованиям и 
к серьезным проблемам интеграции, обусловленным избыточными струк¬ 
турами данных. 

В данной главе рассмотрена система обработки информации с целью 
показать возможность единого подхода к созданию СУБД и прикладной сис¬ 
темы на основе методологии объектно-ориентированного проектирования. Для 
реализации системы использован язык C++, но приемы в значительной сте¬ 
пени применимы и для обычных языков программирования (таких, как 
COBOL). 

ЮЛ. АНАЛИЗ 
Определение границ задачи 

Выше приведены требования к системе регистрации ошибок с очень ма¬ 
лым объемом вычислений и очень большим объемом данных, которые требу¬ 
ется хранить, находить и перемещать. В процессе реализации проекта нам 
придется оперировать декларативными знаниями в гораздо большей степени, 
чем процедурными. Основа проекта — центральный вопрос объектно- 
ориентированного проектирования: какие ключевые абстракции характеризу¬ 
ют словарь предметной области и каковы механизмы управления ими? 



C++. Система регистрации ошибок в программных средствах 


335 


Требования к системе регистрации ошибок 

Программные средства с большим числом ошибок имеют мало шан¬ 
сов на долгую жизнь, что заставляет производителей программного обес¬ 
печения вести учет обнаруженных ошибок. Задача усложняется, если 
фирма ответственна за сопровождение различных программных средств с 
множеством версий и модификаций. Ошибки в программах могут обнару¬ 
живаться пользователями программ, персоналом, осуществляющим сопро¬ 
вождение, группой тестирования и интеграции, контролирующим персона¬ 
лом или программистами. В случае обнаружения ошибка в первую оче¬ 
редь квалифицируется (ошибка в программе, неясность документации или 
простое заблуждение пользователя?), затем определяются ответственные 
за ее появление и приступают к устранению (фиксируют, ликвидируют 
или определяют как невоспроизводимую). Анализ ошибок помогает руко¬ 
водителям групп программистов правильно распределить ресурсы и оцени¬ 
вать готовность программною продукта. 

Наша задача состоит в создании системы регистрации ошибок для 
фирмы, разрабатывающей программные средства [1 ]. Такая система дол¬ 
жна быть рассчитана на наличие многообразия программных продуктов и 
множественность версий для каждого продукта. Поскольку номенклатура 
продукции постоянно изменяется, система должна учитывать и изменения 
требований к СУБД. 



Рис. 10-1. Диаграмма потоков данных 


системе регистрации ошибок. 



На рис. 10-1 показаны основные потоки данных в такой системе. 
Сообщения об ошибках представляются для ознакомления и затем регист¬ 
рируются в центральной базе данных. На рис. 10-1 не отражена множе¬ 
ственность возможных источников сообщений об ошибках и различных- 
способов их представления (звуковой, печатный и электронный). Для об¬ 
наруженной ошибки может быть определен ответственный. В этом случае 
соответствующим лицам передается уведомление об ошибке. Обычно све¬ 
дения об ошибках, получаемые от пользователей, передаются в специаль¬ 
ное подразделение (центр сопровождения) для квалификации. Большой 
процент ошибок здесь отсеивается, поскольку ошибки пользователей 
встречаются гораздо чаще, чем ошибки в программе. Если установлена 
ошибка в продукте, об этом сообщают. Затем выявляется причина ошиб¬ 
ки и ее устраняют. Информация об ошибке корректируется по мере ус¬ 
тановления ее причин, например проверяющий повторил ситуацию воз¬ 
никновения ошибки и установил дополнительную информацию. Разработ¬ 
чик программы модифицирует код программы и устраняет ошибку. Мно¬ 
жество людей на всех этих стадиях имеют доступ к базе данных. В час¬ 
тности, пользователь продукта может обратиться с запросом о состоянии 
дел по конкретной ошибке. Руководитель проекта может запросить отчет 
с перечнем зарегистрированных ошибок для анализа продукции. Группа 
контроля и интеграции программного продукта при выпуске новой версии 
может обратиться к базе данных по вопросу зафиксированных и устра¬ 
ненных ошибок. 

Для простоты будем полагать, что наша система реализует текстовый 
интерфейс пользователя, хотя в последующем интерфейс можно будет ус¬ 
ложнить. Кроме того, допустим, что представление сведений об ошибках 
осуществляется только в форме сообщений на дисплее. По ряду причин 
целесообразно ограничиться одной стандартной СУБД для хранения дан¬ 
ных об ошибках. Однако большое число потенциальных пользователей 
требует обеспечения иллюзии распределенной базы данных. 


По природе подобные системы являются открытыми для расширения. В 
процессе анализа мы подойдем к пониманию того, какие ключевые абстрак¬ 
ции существенны для организации в конкретное время: определим виды дан¬ 
ных, формы сообщений, запросы на обработку и другие аспекты, вытекаю¬ 
щие из задач, решаемых предприятием. Мы употребляем фразу «в конкрет¬ 
ное время», поскольку бизнес не стоит на месте. Он подвержен изменениям 
рынка, а система обработки информации должна учитывать эти изменения. 
Устаревшие программные продукты становятся экономически невыгодными. 
Поэтому мы должны подойти к проектированию системы с учетом ее после¬ 
дующей модернизации. Опыт подсказывает, что вероятнее всего изменяется 
два элемента нашей системы: 

* Типы обрабатываемых данных. 

* Аппаратные средства реализации системы. 

С течением времени появятся новые виды продукции и новые пользова¬ 
тели, а часть старых видов продукции будет снята с производства и эксплу¬ 
атации. При практическом использовании системы может возникнуть 
необходимость в получении дополнительной информации об ошибке (твердые 
копии графических изображений на экране и даже звуковые фрагменты). 
Новые аппаратные средства разрабатываются быстрее, чем программные сис¬ 
темы, и компьютеры устаревают за несколько лет. Однако невозможно так 



C++. Система регистрации ошибок в программных средствах 


337 


быстро заменять сложные программные системы. Затраты на разработку про¬ 
граммных систем часто существенно превышают стоимость оборудования, а 
риск от внедрения новой системы слишком велик, чтобы предприятия в по¬ 
вседневной работе могли позволить себе менять используемые программные 
продукты. Из этого следует вывод о необходимости со временем менять ин¬ 
терфейс пользователя. Для большинства систем обработки информации про¬ 
стой текстовый или экранный интерфейс вполне удовлетворителен. Однако 
удешевление компьютеров и совершенствование графических возможностей 
являются предпосылкой для модернизации интерфейсной методологии. В от¬ 
личие от системы обработки информации в системе регистрации ошибок ин¬ 
терфейс пользователя не играет такой важной роли. Ядром рассматриваемой 
системы является база данных, а интерфейс пользователя представляет собой 
оболочку этого ядра. Вполне реально (и очень желательно) сделать интер¬ 
фейс пользователя открытым для последующих изменений. Для пользовате¬ 
лей, работающих с сообщениями об ошибках, вполне достаточен текстовый 
интерфейс. Печать отчетов на бумаге может осуществляться в пакетной 
форме, хотя отдельные руководители проектов могут обратиться к графиче¬ 
скому интерфейсу в интерактивном режиме. Цель нашего проекта не требу¬ 
ет глубокой проработки этого вопроса, мы лишь упоминаем о возможных 
видах интерфейса. 

Сформулируем два стратегических проектных решения. Во-первых, мы 
будем строить систему на основе одной стандартной СУБД. Специальная 
разработка СУБД в нашей ситуации не имеет смысла, поскольку потребует 
больших дополнительных затрат и не гарантирует нужной гибкости системы. 
Кроме того, стандартные коммерческие СУБД обладают преимуществом и 
могут применяться на широком спектре аппаратных средств (от персональ¬ 
ных компьютеров до суперЭВМ). Во-вторых, мы будем использовать распре¬ 
деленную сеть для реализации проектируемой системы. Для простоты пред¬ 
положим, что база данных размещена на одном компьютере, но доступ к 
ней возможен со стороны множества других компьютеров. Такое проектное 
решение называется методом клиент/сервер, когда компьютер с базой дан¬ 
ных выполняет роль сервера для множества внешних клиентов. Для сервера 
не играют роли конкретные особенности компьютеров клиентов, даже если 
это компьютер со своей локальной базой данных. Такой подход позволяет 
создать систему регистрации в виде неоднородной сети, что делает эту сис¬ 
тему мало чувствительной к изменениям типа используемых аппаратных 
средств реализации. 

Реляционная модель базы данных 

Модели баз данных. По Дейту, база данных — «это среда для хране¬ 
ния данных, обладающая свойствами единства и разделения ресурсов. Под 
единством подразумевается возможность рассмотрения всех файлов базы дан¬ 
ных как единой структуры с минимальной избыточностью. Под разделением 
ресурсов понимается возможность работы нескольких пользователей с любы¬ 
ми фрагментами базы данных» [2]. Централизация управления базой дан¬ 
ных «позволяет разрешить возникающие коллизии, стандартизировать меха¬ 
низмы, обеспечить защиту данных и общность управления» [3]. 

Проектирование базы данных представляет собой достаточно трудную 
задачу, поскольку приходится удовлетворять противоречивые требования. Не¬ 
обходимо обеспечить не только функциональные свойства базы данных, но 
учесть факторы быстродействия и размеры используемой памяти. База дан- 
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ных, которая слишком долго ищет требуемые данные, становится практиче¬ 
ски бесполезной, так же как функциональная неэффективность поглощает 
все ресурсы компьютера или требует многочисленного обслуживающего пер¬ 
сонала. 

Проектирование базы данных имеет много общего с процессом 
объектно-ориентированного проектирования. Методология баз данных рассмат¬ 
ривает проектирование как последовательно-итеративный процесс, требующий 
принятия как логических, так и физических решений [4]. Виорковски и 
Кул называют «объекты, характеризующие базу данных, с точки зрения 
пользователей и программистов, логическими. Физические объекты характе¬ 
ризуют способы фактического хранения данных в системе» [5]. В отличие 
от методологии ООП разработчикам базы данных приходится постоянно в 
процессе проектирования совершать переходы от физической структуры к 
логической и обратно. Способы описания элементов базы данных мало отли¬ 
чаются от описания ключевых абстракций в ООП. Проектировщики СУБД 
для анализа принимаемых решений используют диаграммы соотношений 
между объектами. Как мы ниже увидим, диаграммы классов не только отве¬ 
чают требованию отражения таких соотношений, но и обладают даже боль¬ 
шей выразительностью. Дейт, предположил, что при созданий любой базы 
данных нужно ответить на следующий вопрос: «Какие структуры данных и 
соответствующие им операции должна поддерживать система?» [6]. В зави¬ 
симости от ответа на этот вопрос базы данных относятся к одному из сле¬ 
дующих трех классов (моделей): 

* Иерархические. 

* Сетевые. 

* Реляционные. 

Позже был определен четвертый класс баз данных: объектно-ориентиро¬ 
ванные базы данных (ООБД). Преимущества ООБД были доказаны и 
подтверждены в таких областях, как компьютерная инженерия и компьютер¬ 
ная программная инженерия, где требуется обрабатывать большое количество 
разнородных данных. 

Реляционная модель СУБД. Основу реляционных баз данных составля¬ 
ют «таблицы, колонки которых представляют данные и их атрибуты, а 
строки соответствуют конкретным значениям каждого элемента базы дан¬ 
ных... Кроме того, имеется некоторый набор операторов, позволяющий мани¬ 
пулировать содержанием базы данных и извлекать из нее нужную информа¬ 
цию» [7]. Возьмем для примера фрагмент базы данных, представляющий 
собой опись элементов. Мы имеем здесь компоненты, идентифицирумые но¬ 
мером (PNumber), а также наименование компонент (PName), например, 
следующим образом: 

Компоненты_ 


PNumber 

PName 

0081735 

Резистор, 100 Ом 1/4 Вт 

0081736 

Резистор, 100 Ом 1/4 Вт 

3891043 

Конденсатор, 100 пФ 

9074000 

Микросхема 7400 

9074001 

Микросхема 74LSOO 
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В этой таблице две колонки представляют различные атрибуты. В дан¬ 
ном конкретном случае порядок колонок и строк значения не имеет. Число 
строк может быть любым, но строки не должны повторяться. Заголовок 
PNumber является исходным ключом, который используется для идентифика¬ 
ции записей. 

Компоненты поступают со складов, которые можно охарактеризовать но¬ 
мером, наименованием, адресом и телефоном. Этому отвечает следующая 
форма записи: 


SNumber 

SName 

SAddress 

Telephone 

00056 

Interstate Supply 

1тапИо!"*Й: 

806-555-0036 

3107 

Interstate Supply 

Btt, CA 

408-555-3600 

78829 

Universal Products 


303-555-2405 


Исходным ключом здесь является SNumber, поскольку он однозначно 
определяет нужный склад. Все строки этой таблицы различаются, хотя в 
двух из них имеется одинаковое значение наименования склада. 

Компоненты с разных складов могут поставляться по разным ценам, 
поэтому нам потребуется также таблица цен. Для каждого сочетания компо¬ 
нента/склад в таблице указывается цена: 

Дены ___ 


PNumber 

SNumber 

Price 

0081735 

03107 

$0.10 

0081735 

78829 

$0.09 

0156999 

78829 

$367.75 

7775098 

03107 

$10.90 

6889655 

00056 

$0.09 

9074001 

03107 

$1.75 


Эта таблица не имеет единственного исходного ключа. Для идентифика¬ 
ции строк здесь следует использовать сочетание SNumber и PNumber. Такой 
ключ называется составным. Отметим, что в этой таблице нет имен компо¬ 
нент и складов, поскольку это было бы избыточно — нужную информацию 
можно найти в предыдущих таблицах. Ключи PNumber и SNumber называ¬ 
ются чужие, так как это исходные ключи других таблиц. 

Для ведения учета нам еще потребуется таблица с данными о количе¬ 
стве имеющихся на складе компонент: 
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Наличие 


PNumber 

Quantity 

0081735 

1000 

0097890 

2000 

0156999 

34 

7775098 

46 

6889655 

1 

9074001 

192 


Можно было бы включить количество компонент отдельной колонкой в 
таблицу компонент. Однако мы этого не делаем, поскольку наличие компо¬ 
нент характеризует текущее состояние складов, а таблица компонент содер¬ 
жит всю номенклатуру используемых элементов. Это еще один пример под¬ 
хода к проблеме схожести и различия в дополнение к примеру из гл. 4. 

SQL. Пользователю необходимо иметь возможность выполнения некото¬ 
рого набора стандартных операций над данными указанных таблиц. 
Возможно, придется включить в таблицы новые склады, удалить некоторые 
компоненты или изменить данные о наличности компонент. Следует также 
обеспечить доступ к данным таблиц. Например, мы можем затребовать спи¬ 
сок всех компонент по конкретному складу, а также список компонент, 
удовлетворяющих некоторому количественному критерию. Может, наконец, 
потребоваться исчерпывающий отчет с указанием стоимости заданного набора 
компонент по наиболее дешевому варианту. Такого рода операции реализу¬ 
ются почти во всех реляционных СУБД на языке SQL (язык структурных 
запросов). Язык SQL используется как в программном, так и в интерактив¬ 
ном режиме. 

Основной конструкцией SQL является оператор выбора, существующий в 
следующих формах: 

SELECT <attribute> 

FROM <relation> 

WHERE <condi«on> 

Например, чтобы запросить номера компонент, для которых запас со¬ 
ставляет менее 100 штук, следует записать 

SELECT PART, QUANTITY 
FROM INVENTORY 
WHERE QUANTITY < 100 

Возможны и более сложные запросы. Можно, например, вместо номеров 
компонент затребовать их наименования: 

SELECT PNAME, QUANTITY 

FROM INVENTORY, PARTS 

WHERE QUANTITY < 100 

AND INVENTORY.PART - PARTS.PNAME 
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Такой запрос называется соединением, поскольку в нем объединяются 
два и более условия в одно общее условие. Приведенный выше запрос не 
создает новую таблицу, а лишь возвращает некоторое число строк. Оператор 
выбора может возвращать сколь угодно большое число строк и нужно иметь 
возможность просматривать их последовательно. В языке SQL для этого ис¬ 
пользуется механизм курсора, аналогичный операторам итерации, изложен¬ 
ным в гл. 3. Курсор можно определить следующим образом: 

DECLARE С CURCOR 

FOR SELECT PNAME, QUANTITY 
FROM INVENTORY, PARTS 
WHERE QUANTITY < 100 
AND INVENTORY.PART - PARTS .PNAME 

Для реализации этого соединения нужно записать следующую строку: 
OPEN С 

Чтобы просмотреть соединение построчно, записываем следующий опера¬ 
тор: 


FETCH С INTO NAME, AMOUNT 

После просмотра курсор закрывается командой 
CLOSE С 

Вместо курсора можно сформировать фактическую таблицу с результа¬ 
тами выполнения запроса. Такая таблица называется обзором и может ис¬ 
пользоваться для дальнейших операций наряду с другими таблицами. Напи¬ 
шем, например, операторы создания обзора содержащего наименования ком¬ 
понент, складов, а также стоимость: 

CREATE VIEW V (PNAME, SNAME, COST) 

AS SELECT PARTS.PNAME, SUPPUERS.SNAME, PRICES.PRICE 

FROM PARTS, SUPPLIERS, PRICES 
WHERE PARTS.PNUMBER-PRICES.PNUMBER 
AND SUPPLIERS.SNUMBER—PRICES.SNUMBER 

Обзоры позволяют различным пользователям получить нужную именно 
им информацию из базы данных. Обзоры могут быть независимы от модели 
базы данных и тем самым создают значительную степень свободы. С 
помощью механизма «обзор по обзору* осуществляется защита данных базы 
данных и гарантируется контроль доступа к данным. Отличие обзоров от 
обычных таблиц базы данных состоит в том, что их нельзя произвольно из¬ 
менить. 

Для решаемой нами задачи язык SQL является абстракцией низкого 
уровня. Мы не можем требовать от пользователей системы знания SQL, и 
этот язык не является элементом словаря предметной области. SQL мы бу¬ 
дем использовать только в реализации наших процедур внутри системы, 
скрыв этот язык от пользователя системы. 
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Анализ базы данных 

«Если задана основа представления данных в базе данных, то как опре¬ 
делить логическую структуру, приемлемую для этих данных? Другими сло¬ 
вами, как выбрать нужные соотношения и их атрибуты? Это и является 
сутью проектирования базы данных» [8]. Оказывается, что определение 
ключевых абстракций базы данных — процесс, аналогичный определению 
классов и объектов в методологии ООП. 

Нормализация. Наиболее важной целью проектирования базы данных 
является хранение каждого факта в одном месте. Это снижает избыточность 
информации, упрощает процесс модификации данных, обеспечивает целост¬ 
ность базы данных (внутреннюю устойчивость и непротиворечивость) и сни¬ 
жает объем занимаемой памяти. Достичь этой цели не так легко (и, как 
выясняется, не всегда обязательно). 

Для достижения этой цели разработана теория нормализации (хотя это 
не единственный подход [9]). Нормализация характеризует свойство таблиц 
удовлетворять ряду требований (иметь нормальную форму). Нормальные 
формы имеют несколько уровней, каждый из которых основывается на 
предыдущих [10]: 


* Первая нормальная форма 
(1NF) 

* Вторая нормальная форма 
(2NF) 

* Третья нормальная форма 
(3NF) 


Каждый атрибут является простым значением 
(не распадается на другие атрибуты) 

Таблица соответствует 1NF и каждый атри¬ 
бут определяется своим ключом (атрибуты 
функционально независимы) 

Таблица соответствует 2NF и ни один атри¬ 
бут не содержит фактов о других атрибутах 
(совместная независимость атрибутов) 


Таблицы, соответствующие 3NF, «содержат свойства ключей, всех клю¬ 
чей и ничего, кроме ключей» [11]. 

Все приведенные выше таблицы имеют форму 3NF. Существуют и бо¬ 
лее высокие уровни нормализации (главным образом в отношении многомер¬ 
ных фактов), но для нашей цели они не существенны. В SQL существует 
несколько практических ограничений, которые приводят к тому, что норма¬ 
лизация не может быть единственным критерием проектирования. 

В частности, SQL имеет очень ограниченный набор типов данных (сим¬ 
волы, строки фиксированной длины, целые числа, действительные числа). 
Практические задачи часто выходят за рамки такого ограниченного набора 
типов. Невозможно непосредственно представить в базе данных изображения 
или большие фрагменты текста. Кроме того, SQL не позволяет модифициро¬ 
вать обзоры, полученные в процессе сложных запросов-соединений. 

Анализ предметной области для системы регистрации ошибок. Снача¬ 
ла сформируем список ключевых абстракций, а затем создадим из них нор¬ 
мализованные таблицы. Сообщения об ошибках всегда кем-то инициализиру¬ 
ются (предъявляются). Мы можем проследить источник возникновения сооб¬ 
щений, если будем иметь следующую информацию: 

* Имя предъявителя. 

* Телефон предъявителя. 

* Идентификатор клиента (ID). 
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Каждый клиент имеет свой идентификатор ID в соответствии с лицен¬ 
зией на использование конкретной версии продукта. Регистрация (ID) позво¬ 
ляет контролировать права предьявителя на использование продукта и на 
оказание услуг. Для регистрации необходимы следующие данные: 

* Дата регистрации. 

* Идентификатор версии продукта. 

* Идентификатор клиента. 

Один клиент может быть пользователем нескольких видов продукции. 
Более того, сообщение об ошибке могут передать представители предприятия 
пользователя продукта. Для нас важно убедиться в связи инициатора с 
предприятием-клиентом. Это позволяет выявить случаи «пиратского» исполь¬ 
зования копий программных продуктов. Нам необходима следующая ключе¬ 
вая информация о клиенте: 

* Наименование фирмы. 

* Адрес фирмы. 

Каждый продукт может существовать в нескольких одновременно ис¬ 
пользуемых версиях. Поэтому мы должны иметь следующие данные по каж¬ 
дой версии продукта: 

* Идентификатор продукта. 

* Сведения о версии. 

Кроме того, нужна дополнительная информация о каждом продукте: 

* Наименование продукта. 

* Перечень ответственных групп. 

Под группами ответственных подразумевается следующее: каждый вид 
продукции сопровождается конкретной командой (командами) разработчиков 
и специалистов по эксплуатации. Именно эти команды должны получить 
сообщения об обнаруженных в продукции ошибках. Каждая группа ответст¬ 
венных имеет свой номер, наименование и руководителя, поэтому отметим 
и эти данные: 

* Идентификатор группы. 

* Наименование группы. 

* Руководитель группы. 

Группы состоят из сотрудников компании, информация о которых так¬ 
же существенна для нас: 

* Идентификатор сотрудника. 

* Имя сотрудника. 

* Почтовые атрибуты сотрудника. 

Почтовые атрибуты сотрудника включают, в отличие от полного имени 
адрес электронной почты. Сотрудник может входить в несколько групп и 
быть программистом, специалистом по эксплуатации, обслуживанию и мар¬ 
кетингу. Для клиентов важно знать координаты специалистов по обслужива¬ 
нию и маркетингу. Поэтому в информацию клиента включим следующие 
сведения: 

* Представитель по обслуживанию. 

* Представитель по маркетингу. 

Инициатор (предъявитель) сообщает об обнаружении ошибки в конкрет¬ 
ной версии продукта. Наряду с идентификатором ошибки нам необходима 
следующая информация: 

* Идентификатор предъявителя. 

* Дата предъявления. 

* Приоритет предьявителя. 

* Идентификатор версии продукта. 
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* Вид ошибки. 

* Подробное описание ошибки. 

Подробное описание может иметь различную форму: текст, твердая ко¬ 
пия изображения, рисунок и т.д. Устанавливается группа, ответственная за 
ошибку, а затем конкретный исполнитель. Исполнитель может изменить сле¬ 
дующие данные: 

* Внутренний приоритет. 

* Текущее состояние. 

Состояние характеризует стадию, на которой находится решение конк¬ 
ретного вопроса: 

* Еще не рассматривается. 

* Анализ причин. 

* В процессе устранения. 

* Устранено. 

* Отклонено. 

* Ошибка отсутствует. 

* Ошибка невоспроизводима. 

* Отсутствие действий. 

В сообщении может упоминаться несколько действий по данной ошибке. 
Каждое действие включает анализ, комментарий, тест или объяснения отве¬ 
чающего за устранение ошибки. Действия по сообщению содержат: 

* Описание предпринятых действий. 

* Ответственный. 

* Дата проведения. 

* Идентификатор сообщения. 

При завершении действий по данному сообщению необходимо отразить 
итоговое состояние (факт устранения) и указать другие версии продуктов, 
которые могут содержать ту же ошибку. Это позволит в последующих вер¬ 
сиях учесть обнаруженные ошибки на основе данных: 

* Выполненные действия. 

* Установленные ошибки. 



Рис. 10-2. Диаграмма классов системы регистрации. 
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Рис. 10-3. Продукты, версии, группы и сотрудники. 

И наконец, добавим еще фрагмент информации: 

* Аудиторы. 

Это перечень лиц, которые должны быть уведомлены о произведенных 
действиях. 

Схема системы регистрации ошибок. Мы сформулировали перечень аб¬ 
стракций, отвечающих сути поставленной задачи, но не упорядочили его. 
Для нормализации базы данных необходимо установить иерархию указанных 
видов данных. 

Начнем с самых общих групп данных. Анализ показывает наличие де¬ 
вяти таких групп (кластеров): сообщения об ошибках, сообщения о действи¬ 
ях по выявлению причин, программные продукты, версии продуктов, груп¬ 
пы, сотрудники, клиенты, предьявители и регистрация. Эти проектные реше¬ 
ния приведены на рис. 10-2. 

Диаграмма классов не случайно похожа на схему отношений объектов. 
На ней отмечены количественные характеристики отношений и сделаны не¬ 
которые пояснения (точкой показано направление, к которому относится та 
или другая метка). Из рисунка видно, что группа отвечает за несколько 
продуктов, которые могут иметь версии. Предьявитель (сотрудник фирмы) 
может инициировать сообщения об ошибках в произвольном количестве по 
каждой версии. 

На рис. 10-3 показаны существенные связи между продуктами, версия¬ 
ми, группами и сотрудниками. Простые связи между классами означают от¬ 
ношения использования. Введены также две промежуточные абстракции — 
руководитель группы и член группы — для различения уровня сотрудников. 
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Рис. 10-4. Регистрация и клиенты. 

Из данной диаграммы вытекает структура базы данных: 

PRODUCTS 

product ID 
product name 
RELEASE 

release ID 
product ID 
release date 

GROUPS 

group ID 
group name 
group leader 

EMPLOYEES 

employee ID 
employee name 
employee user name 

Все таблицы имеют форму 3NF. 

Отношения между группами и продуктами, между группами и сотруд¬ 
никами не определены, поскольку такие связи не имеют практического 
смысла. Продукт может включать перечень ответственных, и, наоборот, дан¬ 
ные о группе могут содержать перечень продуктов, связанных с этой груп¬ 
пой. Такие неоднозначные соотношения (1:п и m:n) могут вносить избыточ¬ 
ность, если их неправильно определить. Для определенности введем две 
вспомогательные таблицы: 

PRODUCT RESPONSIBILITIES 
product ID 
group ID 
GROUP ASSIGMENTS 
group ID 
employee ID 

Две колонки в каждой таблице образуют составной ключ. На рис. 10-4 
показана структура классов регистрации и клиентов, которую можно описать 
следующим образом: 
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REGISTRATIONS 

registration ID 

registration date 

release ID 

customer ID 

CUSTOMERS 

customer ID 

company name 

company address 

Field-support representative 

marketing representative 



Результат 


Рис. 10-5. Предъявители сообщений об ошибках, сообщения о 
действиях, изменения аудиторов. 
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Рис. 10-6. Сообщения о действиях по выявлению причин ошибок. 

Вспомогательные таблицы здесь не нужны, поскольку отношения полно¬ 
стью определены. Нам остается определить абстракции предьявителей сооб¬ 
щений об ошибках, сообщений о действиях и изменения аудиторов. Эти ре¬ 
шения приведены на рис. 10-5 и 10-6. 

Из этих двух диаграмм можно составить следующие таблицы данных: 

SUBMITTERS 

submitter ID 
submitter name 
submitter telephone 
customer ID 
PROBLEM REPORTS 

problem report ID 
submitter ID 
date submitted 
submitter priority 
release ID 
problem summary 
detailed problem description 
internal priority 
current status 
fixed in release 
maintenance summary 
AUDITORS 

problem report ID 
employee ID 

MAINTENANCE REPORTS 

maintenance report ID 
maintenance report description 

date created 
problem ID 

Отметим, что мы ввели два подкласса сотрудников. Аудиторы — это 
сотрудники, которые должны уведомляться о любых изменениях в состоянии 
дел (например, о любом сообщении о действиях), а ответственные — это 
сотрудники, производящие действия по сообщениям. 
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Для устранения избыточности в базе данных все таблицы должны быть 
нормализованы. С этой точки зрения приведенные описания являются закон¬ 
ченными (исключая форму описания) и позволяют администратору базы 
данных приступить к описанию схемы на языке SQL. Однако все, что мы 
сделали выше, представляет низкий уровень абстракции. Пользователям сис¬ 
темы не обязательно знать о наличии и видах таблиц в базе знаний. Ниже 
мы рассмотрим проектирование системы на более высоком уровне абстрак¬ 
ции. 


10.2. ПРОЕКТИРОВАНИЕ 
Архитектура процессов 

По ряду причин мы приняли выше проектное решение, по которому 
система регистрации ошибок должна функционировать в распределенной се¬ 
ти. Из этого следует тот факт, что система регистрации не представляет со¬ 
бой одну программу, как в двух предыдущих примерах, а состоит из набора 
взаимодействующих программ, обеспечивающих функциональные свойства си¬ 
стемы. 

Что касается архитектуры процессов, мы прежде всего можем сделать 
вывод о различной роли пользователей в системе регистрации ошибок. Из 
предыдущего анализа можно выделить семь групп пользователей: 

* Предъявители (инициаторы сообщений об ошибках). 

* Ответственные (по устранению причин ошибок). 

* Аудиторы. 

* Руководители групп. 

* Члены групп. 

* Представители по обслуживанию. 

* Представители по маркетингу. 

Анализируя роли этих групп пользователей, можно выделить следую¬ 
щий набор действий: 

* Предъявление сообщений об ошибках. 

* Обработка сообщений об ошибках. 

* Изменение сообщений об ошибках. 

* Формирование сообщений о предпринятых действиях. 

* Запросы в базу данных. 

Просматривая этот перечень, можно заметить, что одна из ролей опу¬ 
щена. Любая база данных содержит огромное количество функций управле¬ 
ния, таких, как архивирование данных, прием-передача данных из различ¬ 
ных внешних источников, диагностические сообщения, измерение характери¬ 
стик базы данных и т.д. Все эти действия осуществляются администратором 
базы данных. Большинство таких функций обеспечиваются стандартными 
СУБД, и мы не рассматриваем их реализацию, а лишь указываем на их 
важное значение. 

Приведенный выше перечень действий (транзакций) соответствует базо¬ 
вым пользовательским функциям системы регистрации ошибок. Такие функ¬ 
ции можно выполнить как в виде отдельных программ, так и в виде общей 
программы с возможностью выбора пользователем конкретной транзакции. В 
любом случае необходимо определить место реализации этих транзакций. 
Одним из решений является возможность реализации любых функций на 
любом компьютере в сети, но за такую универсальность всегда нужно пла¬ 
тить, поэтому другим решением является специализация — закрепление 
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каждой транзакции за отдельным компьютером. В нашем случае решено ис¬ 
пользовать стандартную коммерческую СУБД с централизованной базой дан¬ 
ных. 

На рис. 10-7 показана диаграмма процессов, в которой реализуется 
компромиссное решение. Из рисунка видно, что коммерческая СУБД разме¬ 
щена на отдельном компьютере, который выполняет роль сервера сети. Этот 
компьютер может принадлежать любому классу, начиная от PC и кончая 
мощным компьютером. Перенос данных на различные ЭВМ гарантируется 
использованием стандартной СУБД. Этот же компьютер реализует все функ¬ 
ции DBA. Все остальные компьютеры сети являются равноправными элемен¬ 
тами системы в пределах решаемых ею задач. В результате мы получаем 
неоднородную сеть (сеть, включающую различные типы компьютеров), узлы 
которой не обязательно гарантируют выполнение всех видов транзакций (мо¬ 
гут отсутствовать дисплейные и печатающие устройства). 

Для обеспечения взаимодействия всех элементов системы независимо от 
вида сетевых средств мы должны создать обобщенный механизм связи. На¬ 
личие этого механизма отражено на рис. 10-7. Мы видим, что реализация 
транзакций на любом компьютере осуществляется путем взаимодействия с 
базой данных через механизм удаленного вызова процедур (Remote 
Ppocedure Call). Этот механизм позволяет написать для компьютера А про¬ 
грамму, которая обращается к подпрограмме, написанной на компьютере В. 
Для передачи сообщений об ошибках будем использовать средства электрон¬ 
ной почты. Электронная почта привлекательна тем, что является распрост¬ 
раненным средством для разнородных сетей, а правила пользования ею из¬ 
вестны большинству клиентов. Изложенный подход — типичный пример со¬ 
здания нового механизма на основе уже известных. Использование сущест¬ 
вующих средств (RPC и электронной почты) упрощает нашу задачу (умень¬ 
шает объем работы) и уменьшает степень риска (использует уже проверен¬ 
ные средства). 

На основе рис. 10-7 мы можем строить дальнейшие заключения о фун¬ 
кционировании системы. Например, о том, как клиенты предъявляют сооб¬ 
щения об ошибках. Предъявление сообщений — это скорее вопрос, относя¬ 
щийся к политике бизнеса, а не к технике. На практике допускается, что¬ 
бы пользователь продукта мог выбрать компьютер в сети и послать сообще¬ 
ние. Также можно пропустить все сообщения через специальный централь¬ 
ный узел обслуживания: клиенты сообщают туда письменно или по телефо¬ 
ну об обнаруженных ошибках, а персонал центрального узла вводит эту ин¬ 
формацию в систему регистрации. Выбор того или другого подхода не отра¬ 
жается на принимаемых технических решениях, так как мы создаем общий 
механизм, пригодный для любого варианта реализации. 

Схема базы данных 

Схему базы данных будем создавать, ориентируясь на язык C++. 
Определим, какие классы составляют внутреннюю структуру системы регист¬ 
рации на уровне абстракции реляционной СУБД, не пользуясь словарем 
предметной области. Классы, приводимые в этом разделе (на языке C++), 
соответствуют схеме базы данных (изложенной на языке SQL). 

Наша задача упрощается тем, что уже имеются решения для этих абс¬ 
тракций. На данном уровне абстракции классы сильно структурированы по 
назначению, пригодны в качестве буферов для приема-передачи фрагментов 
базы данных. Для этих классов не определяются специфические операции, 
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но в дальнейшем на основе таких классов будут строиться абстракции более 
высокого уровня, имеющие определенное поведение. 

Причина низкого уровня абстракций состоит в низком уровне SQL. Уже 
говорилось, что в языке SQL набор типов данных очень ограничен. Поэтому 
классы низкого уровня на C++ только отражают типы SQL с учетом про¬ 
блемной специфики всех видов отношений. 

Просмотр всех таблиц, входящих в схему базы данных, позволяет выде¬ 
лить девять элементарных типов данных. Определим эти типы, являющиеся 
общими для всех пользователей системы: 


typedef int ID; 

typedef char* Name; 

typedef char* Address; 

typedef Int Telephone; 

typedef char* Date; 

typedef int Priority; 

typedef char* Summary; 

typedef char* FileName; 

enum Status {Reviewing, InProgress, Fixed, Defer, 

NotAProblem, NotReproducible, NoAction}; 




Puc. JO-7. Диаграмма процессов системы регистрации. 
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Большинство этих определений очевидны. Идентификаторы Ш являются 
обычными числами, а имена и адреса (Names, Addresses) — символьными 
строками. Состояние (Status) включает семь пронумерованных значений, рас¬ 
смотренных выше. Эти определения могут быть легко изменены, что .не 
окажет серьезного влияния на другие проектные решения. 

Определение типа FileName (имя файла) требует некоторого пояснения. 
Мы уже говорили об ограничениях SQL на типы атрибутов. SQL позволяет 
работать со строками переменной длины и двоичными кодами, но в боль¬ 
шинстве реализаций размер данных ограничивается значениями порядка 
256 байт и менее. Для нас такое ограничение является критическим, и мы 
должны его устранить косвенным путем. Для этого выберем файловый спо¬ 
соб хранения и передачи длинных сообщений. Атрибут содержит только имя 
такого файла, а сам файл всегда может быть найден сетевыми средствами. 

В качестве суперкласса для всех видов соотношений введем класс 
Relation, который будет определять все операции подклассов в процессе спе¬ 
циализации суперкласса. Это гораздо удобнее, чем использование обычной 
структуры (structs) в языке С. Абстракции для продукции, версий, групп и 
сотрудников будут выглядеть следующим образом: 

class LowLevelProduct : public Relation { 
public: 

ID ProductlD; 

Name ProductName; 

>; 


class LowLevelRelease : public Relation { 
public: 

ID ReleaselD; 

ID ProductlD: 

Date ReleaseDate; 


class LowLevelGroup : public Relation { 
public: 

ID GroupID; 

Name GroupName; 

ID GroupLeader; 

}; 

class LowLevelEmployee : public Relation { 
public: 

ID EmployeelD; 

Name EmployeeName; 

Name EmployeeUserName; 

>; 


По причинам, которые скоро прояснятся, в названии каждого класса 
используется приставка LowLevel. 

Классы ответственных за продукцию и ответственных групп составляют¬ 
ся из объектов уже определенных классов: 

class LowLevelProductResponsibllity : public Relation { 
public: 

ID ProductlD; 

ID GroupID; 
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class LowLevelGroupAssignment : public Relation { 
public: 

ID GroupID; 

ID EmployeelD; 

}; 

Следующий класс будет выглядеть так: 

class LowLevelProblemReport : public Relation { 
public: 

ID ProblemReportlD; 

ID Submitter; 

Date DateSubmitted; 

Priority SubmitterPriority; 

ID ReleaselD; 

Summary ProblemSummary; 

FileName DetailedProbiemDescription; 

Priority InternatPriority 
Status CurrentStatus; 

ID FlxedlnRelease; 

Summary MaintenanceSummary; 

}; 


Остальные определения классов нижнего уровня достаточно просты и 
для краткости опущены. 

Механизм SQL 

Все описанные выше классы представляют низкий уровень абстракции и 
отражают не столько предметную область, сколько механизмы внутренней 
реализации. Было бы желательно создать абстракции более высокого уровня, 
которые позволят обрабатывать запросы базы данных на уровне объектов, а 
не на уровне фрагментов различных таблиц. Действительно, любая транзак¬ 
ция должна выполнить операции с сообщениями как с неделимыми объекта¬ 
ми, а содержание таблиц должно быть надежно защищено от случайного 
воздействия. 

Построение абстракций на языке SQL. Механизм SQL иллюстрируется 
рис. 10-8, ще показан сервер СУБД (реализованный на отдельном компью¬ 
тере), выполняющий все операции низкого уровня по обработке сообщений. 
В узлах сети размещаются пользователи СУБД, взаимодействующие с серве¬ 
ром для осуществления транзакций системы регистрации. Все транзакции 
выполняются на более высоком уровне абстракций, а пара клиент-сервер от¬ 
вечает за их реализацию в коде низкого уровня. Поскольку этот процесс 
связан с отображением запросов высокого уровня на языке SQL, то мы на¬ 
зываем его механизмом SQL. 

Классы низкого уровня для работы с базой данных уже определены на¬ 
ми и теперь необходимо перейти к разработке классов, отражающих пред¬ 
метную область системы регистрации. Мы выполним краткий анализ пред¬ 
метной области для всех видов транзакций и определим перечень операций, 
которые будут выполняться над объектами высокого уровня. 

Из анализа определяются три исходных вида операций в системе: 

* Предъявление Первичное предъявление (инициирование) сообще¬ 

ния об ошибке. 


23 Гради Буч 
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* Чтение Просмотр сообщений об ошибках для формирова¬ 

ния обобщенных данных (например, перечень всех 
ошибок по конкретной версии продукта). 

* Модификация Изменение сообщения об ошибке (изменение состо¬ 

яния проблемы или действия по устранению). 

Ниже показано, почему в перечень видов операций не включено выяв¬ 
ление причин ошибок. Три вида операций характеризуют три различных ас¬ 
пекта работы с сообщениями: первый вид операции только предъявляет со¬ 
общение (один раз!), другой — связан исключительно с чтением сообщений, 
а последний — допускает и чтение, и модификацию сообщений. Такое раз¬ 
личие хорошо отражается иерархией классов. 

Начнем определение с наиболее общего из абстрактных классов системы 
регистрации. Вариант класса, предназначенного только для чтения, может 
быть следующим: 

class ProblenlReport { 

ProblemReport О; 

ProblemReport (const ProblemReportA); 
virtual -ProblemReport 0; 
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virtual 

virtual 

virtual 

virtual 

virtual 

virtual 

virtual 

virtual 

virtual 

virtual 

virtual 


Submitter 

Date 

Priority 

Release 

Summary 

Description 

Priority 

Status 


Auditors 

MalntenanceReports 


SubmitterOfReport 0 const; 
DateOfReport 0 const; 
SubmitterPriorityOfReport 0 const; 
ReleaseWithProblem 0 const; 
SummaryOfProblem 0 const; 
DescriptionOfProblem 0 const; 
IntemalPriorityOfReport 0 const; 
StatusOFReport 0 const; 

ReleaseWithFix 0 const; 
AuditorsOfReport () const; 
MaintenanceReportsForProblem 0 const; 


Submitter 

Date 

Priority 

Release 

Summary 

Description 

Priority 

Status 

Release 

Auditors 

MalntenanceReports 

virtual int 

virtual ID 

private: 

ID ProblemReportID; 

}: 


TheSubmltter; 

TheDate; 

TheSubmltterPriority; 

TheProblemRelease; 

TheSummary; 

TheDescription; 

ThelntemalPriority; 

TheStatus; 

TheFlxedRelease; 

TheAudltors; 

TheMaintenanceReports; 

SetProblemReportID (ID AnID); 
IdOfProblemReport 0 const; 


Предполагается, что видимость классов и типов, входящих в данный 
класс, обеспечена (Release, Status, Priority и т.д.). 

На языке C++ необходимо определить для каждого класса конструктор 
и деструктор, что сделано в приведенном описании. Структура класса защи¬ 
щена для всех пользователей, кроме подклассов данного класса (декларация 
protected:). Для обеспечения доступа к структуре данных этого класса опре¬ 
делены операции-селекторы. Возможность переопределения функций в под¬ 
классах реализуется с помощью квалификатора virtual. Функции определяют¬ 
ся в качестве фактических (виртуальных) всегда, когда нет явных причин 
отказаться от их последующего переопределения. 

Особый случай представляет объект класса, обозначенный именем 
ProblemReportID. Он объявлен обособленным (private), чтобы не допустить 
его изменения пользователями. Для однократной записи данных в этот объ¬ 
ект введена функция SetProblemReportID. Поскольку указанный объект за¬ 
щищен от доступа со стороны подклассов, переопределенная функция 
SetProblemReportID не сможет изменить значение объекта ProblemReportID. 
Следовательно, исключается возможность несанкционированного изменения 
данных. Такой способ защиты данных существенно необходим, поскольку в 
дальнейшем будет показано, насколько важно обеспечить уникальность иден¬ 
тификатора сообщений для целостности базы данных. 

Теперь специализируем базовый класс, добавив в него средства записи 
данных. Класс ModifiableProblemReport наследует от своего суперкласса опе¬ 
рации-селекторы и поэтому может выполнить действия чтения-записи: 
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enum Boolean {False, True}; 

class ModifiableProblemKeport : public ProblemReport { 
public: 


ModifiableProblemReport (); 

ModiflableProblemReport (const ModiflableProblemReport*); 
virtual -ModiflableProblemReport 0; 

virtual int SetlntemalPriority (Priority* Apriority); 
virtual int SetStatusOfReport (Status* AStatus); 
virtual int SetReleaseOfFix (Release* ARelease); 
virtual int AddAuditor (Auditor* AnAuditor); 
virtual int RemoveAuditor (Auditor* AnAuditor); 

virtual int AddMaintenanceReport (MaintenanceReport* AMaintenanceReport); 
virtual int Update 0; 

virtual Boolean IsUpdated 0 const; 

}; 


Язык C++ не обеспечивает механизма обработки исключительных ситуа¬ 
ций, поэтому мы должны определить их самостоятельно. Операция-модифи¬ 
катор SetReleaseOfFix возвращает целое число. При правильном завершении 
операции возвращается ноль, если возникает ошибка при выполнении дейст¬ 
вий, возвращается код этой ошибки. 

Отметим наличие операций введения и исключения аудиторов, позволя¬ 
ющих корректировать перечень сотрудников для уведомления с течением 
времени. Определена также операция добавления новых сообщений о ходе 
рассмотрения ошибки (но удаление таких сообщений запрещено, так как 
они должны храниться для анализа). 

Теперь специализируем класс ProblemReport в подкласс 
InitialProblemReport, позволяющий осуществить регистрацию сообщения в ба¬ 
зе данных: 


class InitialProblemReport : public ProblemReport { 
public: 


InitialProblemReport 0; 

InitialProblemReport (const InitialProblemReport*); 
virtual -InitialProblemReport (); 

virtual int SetSubmitter (Submitter* ASubmitter); 
virtual int SetSubmitterPriority (Priority* Apriority); 
virtual int SetRelease (Release* ARelease); 
virtual int SetSummary (Summary* ASummary); 
virtual int SetDescription (Description* ADescription); 
virtual int SubmitProblemReport 0; 
virtual Boolean IsSubmltted 0 const; 


Аналогично определяются классы для следующих ключевых абстракций 
(текст не приводится): 


Auditor 

Auditors 

Creator 


Подкласс от Employee — аудитор 
Множество Auditor 

Подкласс от Employee — ответственный 
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* Customer 

* Customers 

* Description 

* Employee 

* Employees 

* Field-Representative 

* Group 

* Group Leader 

* Group Member 

* Maintenance-Report 

* Maintenance-Reports 

* Product 

* Products 

* Registration 

* Registrations 

* Release 

* Releases 

* Submitter 

* Submitters 


Клиент 

Множество клиентов 

Подробное описание проблемы 

Базовый класс — сотрудник 

Множество сотрудников 

Подкласс от Employee — представитель по 

обслуживанию 

Множество сотрудников 

Подкласс от Employee 

Подкласс от Employee 

Информация о причинах ошибки 

Множество сообщений 

Продукт 

Множество продуктов 
Регистрация пользователя продукта 
Множество регистраций 
Версия продукта 
Множество версий 
Предьявитель сообщений 
Множество предьявителей 


Эти абстракции соответствуют словарю предметной области и позволяют 
пользоваться транзакциями, не вникая в реализацию на низком уровне 
(SQL -процедуры). Кроме того, наличие множества однотипных операций в 
процессе обслуживания транзакций (форматирование вывода на экран, об¬ 
служивание запросов и т.д.) позволяет создать множество общедоступных 
процедур. 

Устранение семантических расхождений. Вернемся к вопросу о наличии 
программного интерфейса с абстракциями уровня базы данных. Имеется воз¬ 
можность (например, для реляционной СУБД Oracle) вызова из программы 
на C++ процедур создания курсора, оперативов SQL, отмены запросов и 
т.д. [12]. Для программиста обеспечивается доступ ко всем ресурсам реля¬ 
ционной базы данных, включая создание таблиц, обзоров, выборок, модифи¬ 
кации и удаления данных. Такие возможности представляют собой люк для 
доступа к базе данных и позволяют реализовать сколь угодно сложные при¬ 
кладные программы. 

Однако остается определенное расхождение между программным интер¬ 
фейсом C++ и классами высокого уровня абстракции типа ProblemReport. 
Объект класса ModifiableProblemReport является элементарной абстракцией 
при выполнении транзакций, но его внутренняя реализация требует обраще¬ 
ния к данным нескольких таблиц. Модификация сообщений может выпол¬ 
няться только отдельно для каждой таблицы, так как SQL не обладает 
свойствами модификаций соединений. Следовательно, необходимо осущест¬ 
вить связь между этими двумя уровнями абстракций, что является не со¬ 
всем простой задачей. 

Устранение семантических расхождений — одна из главных причин со¬ 
здания объектно-ориентированных баз данных. Для решения этой задачи 
рассмотрим подробнее два вида преобразования данных. Допустим, что нуж¬ 
но для конкретного продукта определить ответственную группу. Будем счи- 
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тать, что такая ответственная группа для каждого продукта только одна. 
Начнем определять классы Product и Group: 

class Group { 
pibllc: 

virtual Name NameOfGroup 0 const; 

}; 

class Product { 
pibllc; 

virtual Group GroupResponsibleForProduct О const; 

protected: 

Group ResponsibleGroup; 

>; 


Имея объект класса Product, мы можем записать следующий оператор: 
TheName - TheProduct.GroupResponsibleForProductO.NameOfGroupO 

При выполнении данного оператора возвращается наименование ответст¬ 
венной группы. Этот оператор не осуществляет операций над объектами, со¬ 
ставляющими структуру класса. Конструктор объекта TheProduct не получа¬ 
ет значений составляющих объектов. Идентификатор группы может быть 
получен независимо от других данных. При вызове оператора 
GroupResponsibleForProduct происходит следующее: 

// если объект Group уже считан из базы данных, то 

// возвращается объект Group 

// выполняется оператор SQL для выбора данной группы 

// создается объект Group 

// возвращается объект Group 

В этом алгоритме доступ к базе данных осуществляется только при не¬ 
обходимости получения новой порции информации. В противном случае по¬ 
требовалось бы больший объем памяти для дублирования данных по той же 
группе. 

Теперь рассмотрим операцию Update, определенную в классе 
ModifiableProblemReport. Операция Update (изменение данных) является пер¬ 
вичной транзакцией. Однако реализация этой операции не может быть про¬ 
стой и требует выполнения ряда функций с таблицами базы данных (с уче¬ 
том существования и других процессов в системе). Кроме того, должна су¬ 
ществовать возможность отмены запроса в случае каких-либо ошибок. То же 
можно сказать и о других видах преобразования данных. Операция Update 
выполняется следующим образом: 

// фиксируются (блокируются) все таблицы, входящие в соединение 

// для каждой из таблиц 

// модифицируются данные 

// таблицы деблокируются для последующего использования , 

Можно отметить, что приведенные примеры имеют много общего: рабо¬ 
та ведется с несколькими таблицами, а внутри таблиц — со столбцами и 
строками. Поэтому целесообразно ввести следующие промежуточные классы: 

* Table (таблица) 

* Column (столбец) 

* Row (строка) 
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Эти классы являются аналогами соответствующих элементов SQL. В 
дальнейшем определяются специализированные подклассы: 

* DeferredRecord (отложенная запись) 

* DeferredField (отложенное поле) 

которые реализуют отложенный доступ к данным. Это позволит создать 
классы Group и Product путем смешивания классов низкого уровня (исполь¬ 
зуя множественное наследование). 

Мы не будем более подробно останавливаться на описании таких про¬ 
межуточных классов, поскольку они не вносят новых существенных элемен¬ 
тов в процесс проектирования. 

Механизм передачи сообщений 
Из требований, предъявленных к системе, следует, что необходимо еди¬ 
ным способом реализовать две важные функции: 

* Уведомление руководителей и членов групп, ответственных за каждое со¬ 
общение. 

* Уведомление аудиторов (в частности, представителей по обслуживанию), 
отслеживающих ход рассмотрения ошибок. 



Применения 


Мы уже приняли решение по использованию электронной почты для 
передачи сообщений в сети. Это позволяет воспользоваться уже имеющимися 
средствами и интегрировать систему регистрации в хорошо известную инф¬ 
раструктуру. 

Использование средств электронной почты. Механизм передачи сообще¬ 
ний показан на рис. 10-9. Здесь, так же как в случае механизма SQL, уз¬ 
лы сети являются пользователями базы данных, которая реализована на от¬ 
дельном компьютере-сервере. Каждый узел сети имеет локальный сервер 
электронной почты с программируемым интерфейсом для передачи сообще¬ 
ний удаленным пользователям. Сообщения читаются либо самими пользова¬ 
телями, либо фоновыми процедурами. 

Рассмотрим теперь вытекающие из данного решения следствия. Анализ 
исходных требований приводит к следующему перечню операций с использо¬ 
ванием данного механизма связи: 

* При предъявлении нового сообщения об ошибке, оно направляется в об¬ 
служивающий центр для предварительной классификации. 

* Если требуется предпринять дальнейшие действия (ошибка 
подтверждается), в обслуживающем центре определяются группы, ответст¬ 
венные за выявление причин. 

* Руководители групп периодически просматривают поступающие сообщения 
и передают их конкретным сотрудникам (членам этих групп). 

* По мере выяснения причин ошибок, члены групп формируют соответству¬ 
ющие сообщения или передают другим группам или программистам. 

* После окончательного выявления причин ошибки соответствующее сообще¬ 
ние «закрывается» с уведомлением клиентов через представителей по об¬ 
служиванию или маркетингу. 

* В любой момент времени заинтересованные лица (аудиторы) могут запро¬ 
сить информацию о состоянии зарегистрированных сообщений; любое из¬ 
менение состояния дел доводится до всех аудиторов автоматически. 

Программный интерфейс с электронной почтой может иметь следующий 


// <mailer.h> 

typedef char* UserName; 

typede UserName* UserName []; 

int CreateMailBox (UserName AUser); 

int OpenMailBox 0; 

int CloaeMailBox 0; 

int DisplayHeaders 0; 

int ReadMessage (int MessageNumber); 

int Reply 0; 

int SendMessage (UserName ToUser, 

UserName CC, 

char* Subject, 

char* Text); 

int NumberOfMessage 0; 
int NumberOfUnreadMessage 0; 

Этот интерфейс не удовлетворяет требованиям ООП, но можно найти 
компромиссное решение. Нам нужно создать смешанный класс, который со¬ 
ответствует объектам, связанным электронной почтой. Основу поведения это¬ 
го класса составляет возможность пересылать объекты по электронной почте: 
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Рис. 10-10. Диаграмма классов сообщений. 

II <mailer mixin.h> 

♦include «tnailer.h» 

class MallerMixln { 
public: 

Int Notify (UserName Destination, UserNames CopiesTo); 

protected: 

virtual char* SubjectOfMessage 0 - 0; 

virtual char* TextOfMessage 0 - 0; 


SubjectOfMessage и TextOfMessage являются пустыми виртуальными 
функциями и должны быть определены в подклассах данного абстрактного 
класса. Функция Notify проста и типична для смешанных классов: 

int MaiierMixin::Notify (UserName Destination, UserNames CopiesTo) { 
return SendMessage (Destination, CopiesTo, 

SubjectOfMessage 0, TextOfMessage 0); 

Путем смешения нужных форм поведения мы можем сформировать тре¬ 
буемые нам классы. Приведем пример класса модифицируемого сообщения 
для пересылки по электронной почте: 

class MailableModifiableProblemReport : public ModifiableProblemReport, 

public MailerMixin { 

protected: 

virtual char* SubjectOfMessage 0; 

virtual char* TextOfMessage 0; 

} 


Иерархия классов сообщений показана на рис. 10-10. Объекты приве¬ 
денного выше класса объединяют свойства ModifiableProblemReport с возмож¬ 
ностью уведомления аудиторов и других групп пользователей. Реализация 
этого класса завершается определением функций SubjectOfMessage и 
TextOfMessage, содержащих краткое изложение сообщения и его идентифи¬ 
катор. 
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Рис. 10-11. Механизм формирования-отмены запросов. 

Надежность сетевых коммуникаций. Из рис. 10-9 видно, что серверы 
электронной почты составляют связь между узлами сети. Допустим, что эти 
серверы реализуют процедуры обслуживания ошибочных ситуаций. Напри¬ 
мер, при нарушении связи с каким-либо узлом сети сервер почты попытает¬ 
ся сам восстановить эту связь, либо передаст сообщение о невозможности 
установления связи с конкретным абонентом. 

Это создает уверенность в том, что сообщения не могут просто исче¬ 
зать, а возникающие сбои определенным образом обрабатываются. Сервер 
базы данных должен иметь гарантированную связь со своими пользователя¬ 
ми. Необходимо, в частности, обеспечить совместное согласованное функцио¬ 
нирование классов сервера и пользователя в случае нарушения связи между 
ними. Для обеспечения надежности придадим этим классам специальные 
свойства: 

* Пользователи базы данных хранят очередь запросов на обслуживание. По 
мере реализации запросов очередь ликвидируется, но при нарушении свя¬ 
зи запросы накапливаются. 

* Сервер базы данных сообщает своим пользователям о принятии или от¬ 
клонении запросов, чтобы они соответствующим образом отреагировали на 
эти факты. 

Принятые нами проектные решения отвечают правилам ООП: по мере 
разработки проекта выполняется проверка логичности выбранной совокупно¬ 
сти объектов и их связей. В результате формируются четко разграниченные 
ключевые абстракции и механизмы. 

10.3. РАЗВИТИЕ ПРОЕКТА 
Общие действия 

Анализ вариантов. Чтобы выявить механизмы в системе регистрации 
ошибок, надо проследить за циклом прохождения какого-либо частного сооб¬ 
щения. На рис. 10-11 показаны основные объекты, взаимодействие которых 
определяет процесс функционирования системы. 
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Причиной активизации действий является уведомление разработчика о 
получении нового сообщения, которое поступает с помощью средств элект¬ 
ронной почты. На основе полученной информации разработчик делает запро¬ 
сы в базу данных, в результате чего появляются экземпляры объектов клас¬ 
са problemReport (или его подклассов). В общем случае число объектов-сооб¬ 
щений может быть произвольным, например в случае запроса отчетов отно¬ 
сительно конкретного продукта за последний месяц. Ответственный разработ¬ 
чик просматривает эти сообщения на терминале, а при необходимости дела¬ 
ет твердую копию для последующего анализа; может быть также сформиро¬ 
вано контрольное сообщение о результатах анализа сообщения. 

Здесь возникает потенциальная возможность конфликта: пока разработ¬ 
чик А ведет анализ полученного сообщения, другой разработчик В может 
внести новые сообщения. В более общей формулировке необходимо создать 
механизм контроля и управления параллельными событиями, что характерно 
для любых параллельных систем. Аналогичная ситуация имеет место при 
бронировании мест на авиалиниях агентами, находящимися в различных го¬ 
родах. 

Неверно было бы ставить вопрос о том, как устранить этот конфликт; 
следует поставить другой вопрос — как должна функционировать система. 

Ответ на последний вопрос состоит в следующем: при попытках разра¬ 
ботчика А внести изменения в состояние зарегистрированной проблемы, дол¬ 
жно формироваться сообщение о запрете подобных действий, так как уже 
имеются более ранние версии анализа причин ошибки. После этого ответст¬ 
венному разработчику предстоит сделать выбор: отказаться от своего реше¬ 
ния, поставить его в очередь, либо прямо связаться с разработчиком В. В 
любом случае управление передается от системы к пользователю. 

Выбор решения. Теперь мы попробуем реализовать принятые принципи¬ 
альные решения. Существует три возможных проектных варианта. В первом 
варианте базу данных можно сделать действительно распределенной, а не 
имитировать это качество на централизованной базе данных. В этом случае 
любые изменения со стороны пользователей вызывают широковещательные 
сообщения по всем возможным направлениям. Такой подход имеет сущест¬ 
венное преимущество, связанное с почти полным отсутствием необходимости 
синхронизации сообщений. Однако дополнительная загрузка вычислителей и 
коммуникаций при этом заставляет отказаться от такого решения. 

Во втором варианте на каждом сообщении можно ставить временную 
метку. Это не требует больших затрат вычислительной мощности и прорабо¬ 
тано теоретически, но практически неосуществимо. Чрезвычайно трудно в 
разнородной сети установить единое значение времени. Не помогает даже 
передача значения времени по сети, поскольку она требует прерывания се¬ 
тевых процессов с определенной, достаточно большой частотой. Следователь¬ 
но, этот вариант непригоден. 

Третий вариант — самый простой. Каждое сообщение имеет свой осо¬ 
бый идентификатор, сохраняющийся при всех изменениях. Копии сообщения 
дополняются специальным объектом VersionNumber, обозначающим версию 
сообщения. Вначале значение такого объекта равно нулю. При каждом обра¬ 
щении к базе данных сервер СУБД увеличивает номер версии, который 
впоследствии учитывается в процессах синхронизации. 

Предположим, что разработчик А сделал запрос относительно сообщения 
Р впервые. Номер версии полученного сообщения будет 1. Обратившиеся по 
той же проблеме разработчики В и С получат сообщения с версиями 2 и 3. 
Предположим, что В попытается внести изменения в состояние проблемы. 
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Номер версии измененного сообщения (у разработчика В) станет равным 4. 
Попытки разработчиков А и С внести свои изменения в сообщение Р будут 
предотвращены, так как в базе данных уже имеется сообщение с более вы¬ 
сокой версией. 

Мы останавливаемся на этом подходе из-за его предельной простоты'и 
универсальности. Для реализации изложенного принципа введем еще один 
смешиваемый класс для включения его в соответствующие классы-сообще- 


class VersionNumberMixin { 
public: 

VersionNumberMixin О; 

VersionNumberMixin (const VersionNumberMLxin&); 
virtual -VersionNumberMixin 0; 

lnt VersionNumber 0 const; 


protected: 


int SetVersionNumber (int ANumber); 
void IncrementVersionNumber (); 


bit TheVeisionNumber, 


В этом классе отсутствуют виртуальные функции, поскольку нет необ¬ 
ходимости переопределять функции в подклассах. 

Объект TheVersionNumber инициализируется конструктором с нулевым 
значением, а селектор позволяет читать его значение: 

int VersionNumberMlxln::VersionNumber () { 
return TheVeisionNumber; 

>: 


Функция IncrementVersionNumber увеличивается на 1 номер версии: 
void VeisionNumberMixin::IncremenVersionNumber О { 



Функция SetVersionNumber позволяет установить номер версии только, 
если заданный номер больше текущего: 


int VeisionNumberMbtin::SetVersionNumber (int ANumber) 
if (ANumber > TheVeisionNumber) 


return TheVersionNumber - ANumber; 


{ 


} 


return 0; 


Действия пользователя. Выше мы уже определили семь функций поль¬ 
зователей. Все они различны, поэтому создадим иерархию класса сотрудни¬ 
ков с подклассами предъявителя, аудитора, руководителя группы и т.д. 
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Предполагается наличие соответствующих классов транзакций, предназначен¬ 
ных для смешения. Например, предьявитель, аудитор,. представитель по об¬ 
служиванию и представитель по маркетингу имеют возможность иницииро¬ 
вать сообщения, но не могут их модифицировать. Напротив, руководители 
групп и ответственные разработчики кроме запросов к базе данных могут 
вносить в них изменения. 

Где должны выполняться такие действия, как модификация сообщений? 
Эти действия могут инициироваться пользователем, но не выполняться им. 
При этом должны быть обеспечены надежность и безопасность системы пу¬ 
тем предоставления каждому пользователю строго ограниченных и контроли¬ 
руемых ресурсов. 

Это достигается путем смешения классов, вносящих свои аспекты пове¬ 
дения, например, следующим образом: 

class Update { 
public: 

Updater (ModifiableProblemReport& AReport); 

Updater (const Updateri); 
virtual -Updater 0; 

virtual Int CommltTheReport 0; 

ModifiableProblemReport ReportToBeUpdated 0 const; 

private: 

ModifiableProblemReport TheReport; 


Для пользователей, которым разрешено изменение информации, опреде¬ 
ляется следующий класс: 

class EmployeeWithUpdateRlghts : public Employee, public Updater { 
public: 

EmployeeWithUpdateRlghts (ModifiableProblemReport^ AReport); 

}; 

Такие же классы определяются для других видов функций пользовате¬ 
ля. 

Утилиты и генераторы версий 

Выделение утилит. Стиль проектирования, основанный на использова¬ 
нии стандартных механизмов, не является догмой. Мы могли бы создать 
специальную базу данных или реализовать собственный «доморощенный» 
протокол связи, чтобы обеспечить защиту данных и уведомление о сообще¬ 
ниях. Однако мы предпочитаем, где возможно, использовать стандартные 
средства. Это оправдывается, особенно в проектах, имеющих последователь¬ 
но-итеративный характер, поскольку гарантируется надежность используемого 
кода и более просто осуществляется адаптация к требованиям задачи. 

Уже говорилось, что проектирование базы данных представляет собой 
последовательный-итеративный процесс, соответствующий методологии ООП. 
Единственный способ убедиться в верности каждого принимаемого проектного 
решения — пробная эксплуатация созданной системы. Комбинация анализа, 
тестирования и личного опыта приближает нас к принятию верных реше¬ 
ний, но практика требует «прощупать» первые версии базы данных, чтобы 
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адаптировать ее к конкретным условиям повседневной эксплуатации. Хав- 
ришкевич [13] утверждает, что все основные неувязки в базах данных, ко¬ 
торые можно выявить в процессе проектирования и эксплуатации, требуют 
лишь небольших усилий для устранения и значительного улучшения харак¬ 
теристик. Приведем их перечень: 

* «Слишком много логических записей участвует в осуществлении запроса. 

* Слишком много шагов доступа к данным требуется для удовлетворения 
запроса. 

* Слишком много вспомогательных файлов и операций сортировки. 

* Слишком много физических записей требуется для удовлетворения запро- 


* Чрезмерен объем требуемой памяти. 

* Перегрузка функциями СУБД или ОС*. 

Используя стандартные средства, мы можем начать реализацию и на¬ 
стройку на более ранних стадиях проекта. Кроме уже рассмотренных меха¬ 
низмов, мы должны создать программный интерфейс, связывающий все клю¬ 
чевые элементы системы. С учетом уже определившейся инфраструктуры в 
поле нашего зрения попадают две группы специальных средств: утилиты и 
генераторы версий. 

Под утилитами понимаются наборы сложных операций, относящихся к 
одному или нескольким классам. В гл. 3 было показано, как происходит 
увеличение числа утилит класса по мере уточнения программистом особен¬ 
ностей работы программы. Чтобы не увеличивать число процедур-утилит в 
системе, целесообразно собрать их в одном месте и сделать общедоступными. 

О некоторых утилитах мы уже говорили, но анализ предметной области 
позволяет выделить еще несколько кандидатур на роль утилит: 

* Утилиты запросов 


* Утилиты почты 


* Утилиты регистрации 


Выражения, позволяющие программисту реализо¬ 
вать запросы высокого уровня (не обращаясь к 
SQL). 

Общепользовательские средства связи по элект¬ 
ронной почте, включая передачу сообщения 
группе пользователей по списку, или особые 
формы форматирования сообщений. 

Средства регистрации информации о работе всей 
системы в целом (сбои сетевых средств, откры¬ 
тие и закрытие базы данных и т.п.). 


Рассмотрим подробнее последнюю группу утилит, используемых для ре¬ 
гистрации различных видов событий, происходящих в системе. Можно выде¬ 
лить следующие виды событий: 

* Отладочные сообщения. 

* Сообщения о выполнении запросов. 

* Сообщения об ошибках. 

* Предупреждающие сообщения. 

* Сообщения о сбоях в системе. 

* Справочные уведомления. 

Каждому из таких видов событий может соответствовать свой класс. Но 
благодаря некоторой общности целесообразно реализовать их в виде подклас¬ 
сов суперкласса Message: 
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class Message { 
public: 

Message (char* TheString); 
Message (const Messaged); 
virtual -Message 0; 
virtual char* Value 0; 

private: 

char* TheValue; 


Формы представления различных видов сообщений также отличаются, 
например: 

* Отладка 89/08/25 09:41:06 

* Выполнено 89/08/25 09:43:06 

* Ошибка 89/08/25 09:41:06 


* Предупреждение 89/08/25 10:00:76 И! 

* Сбой 89/08/25 11:41:06 ♦♦♦ 

* Уведомление 89/08/25 23:16:57 

Общим для всех сообщений является наличие даты и времени і 
никновения. Различия состоят в специальных символах перед сообщением. 
Теперь определим класс Log, который лишь заносит сообщения в файл: 


Создано временное окно 
Копирование завершено 
Невозможно отправить 
сообщение 
Недостаточно места 
Пароль неверен 
Ожидание ввода пароля 


class Log { 

Log О; 

Log (const Log&); 
virtual -Log 0; 

virtual int Open (char* AFile); 

virtual Int Close 0; 

virtual void Put (Message* TheMessage); 


ofstream TheFlIe; 


Можно добавить утилиту Filter, которая позволяет читать файлы реги¬ 
страции событий и делать из них соответствующие выборки: 

int Filter (File *LogFile, 

File ‘Destination, 

Boolean IncludeDebugMessages, 

Boolean IncludeSuccessMessages, 


Boolean IncludeWarningMessages, 


Boolean IncludeNotes); 

Используя эту утилиты, можно строить более сложные вспомогательные 
средства. Ниже мы рассмотрим такие вспомогательные средства, особенно 
полезные для утилит регистрации. 

Назначение генераторов версий. Система регистрации ошибок может 
содержать большое число форм и видов сообщений. Реализация в большой 
системе этих видов и форм не представляет труда, но чрезвычайно утоми¬ 
тельно, поэтому в коммерческих приложениях популярны генераторы версий 
(4GL для языков четвертого поколения). 
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Рис. 10-12. Утилиты транзакций. 

Из рис. 10-12 видно, что все транзакции, связанные с пользователями, 
применяют утилиты сообщений и графического интерфейса. Они могут авто¬ 
матически создаваться специальными генераторами, которые на основе спе¬ 
цификаций сообщений и видов индикации формируют нужные шаблоны. За¬ 
дача проектировщика, таким образом, сводится не к программированию со¬ 
тен видов графических сообщений, а к созданию одного-двух генераторов 
для формирования таких утилит. Подобный подход на практике существенно 
сокращает объем программного кода для хорошо формализованных приложе¬ 
ний. 

Проектирование генератора версий представляет самостоятельный 
интерес и здесь не рассматривается. Программисты могут воспользоваться 
коммерческими версиями таких генераторов при необходимости. Написать 
собственный проблемно-ориентированный генератор с использованием методо¬ 
логии ООП. 

Модульная архитектура 

В процессе развития проекта мы создали ряд классов и утилит, состав¬ 
ляющих несколько файлов. Опыт подсказывает, что система регистрации 
ошибок в полном объеме составит 20—30 тысяч строк кода на языке C++. 
Отказ от языка C++ и выявления общности между ключевыми абстракциями 
(не объектно-ориентированная версия системы) приведет к увеличению раз¬ 
мера кода примерно на 50%. 

Поскольку мы создаем систему, а не отдельную программу, нам необ¬ 
ходимо как можно раньше установить архитектуру модулей. Соответствую¬ 
щее проектное решение отражено на рис. 10-13. Как и следовало ожидать, 
система глубоко структурирована. Классы и объекты нижнего уровня отнесе¬ 
ны к сетевой подсистеме, в которой реализуется механизм связи. Подсисте¬ 
ма СУБД содержит средства SQL с классами- высокого уровня, а подсистема 
транзакций различные утилиты и генераторы версий. Самый верхний поль¬ 
зовательский уровень представляет подсистема User Application (пользова¬ 
тельские приложения). 

Предложенная структура не только содержит форму физической органи¬ 
зации модулей в систему, но и позволяет распределять ресурсы группы про¬ 
граммистов. Впоследствии она станет основой организации эксплуатации вер¬ 
сий системы. При распределении модулей учитывалось и то, насколько часто 
в той или другой подсистеме возможны изменения. 
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Рис. 10-13. Диаграмма модулей системы регистрации. 


10.4. МОДИФИКАЦИЯ 

Расширение функциональных свойств 

После получения действующей версии системы потребуется некоторое 
время для работы с ней администратора базы данных. Если наша система 
заменила ранее существовавшую, администратор может реализовать перенос 
уже существующих данных в новую систему. Этому поможет то, что мы 
предусмотрели для этого в системе ряд инструментальных вспомогательных 
средств. Могут выявиться ошибки нашего анализа. Причина этого не обяза¬ 
тельно состоит в нашей некомпетенции, а может объясняться пбстоянным 
совершенствованием всех видов деятельности, в том числе и бизнеса. 

Рассмотрим возможность внесения в систему какого-либо изменения. 
Допустим, что предъявитель сообщения ввел данные об ошибке, относящейся 
к нескольким версиям различных программных продуктов. Возможно, что 
два сообщения будут содержать сведения об одной и той же ошибке, а нам 
не хотелось бы дважды тратить усилия на анализ. Возникает потребность в 
механизме, позволяющем расщеплять или группировать сообщения. Для это¬ 
го требуется создать смешиваемый класс Genealogy, позволяющий реализо¬ 
вать между сообщениями отношения предок-наследник. Если сообщение Р 
расщепляется на X и Y, то Р является предком для X и Y, а они в свою 
очередь наследниками Р. То же относится и к процессу группировки. 

Учитывая это, внесем изменения в реализацию транзакций подклассов 
класса ProblemReport. При этом изменение расщепленного сообщения сводит¬ 
ся просто к изменению его наследников. Для обеспечения координации из¬ 
менения одного из наследников сообщают аудиторам, связанным со всеми 
исходными сообщениями. Внесение в систему существенных функциональных 
изменений укладывается в рамки принятых проектных решений. 

24 Гради Буч 
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Изменение исходных требований 

Предположим, что мы решили дополнить систему мощным графическим 
интерфейсом, позволяющим легко работать служащим без специальной под¬ 
готовки. Оказывается, что основа системы при этом сохранится. Все меха¬ 
низмы, кроме генератора версий, остаются без изменений. Независимость 
механизмов, основанная на ожидании изменений лишь в некоторых из них, 
позволяет реализовать сколь угодно развитый графический интерфейс поль¬ 
зователя. В отличие от интерфейса, рассмотренного в предыдущей главе, в 
системе регистрации ошибок требуется другой многооконный интерфейс, со¬ 
здание которого мы здесь не рассматриваем. 

Дополнительная литература 

Особенности реляционных баз данных подробно описаны в работах Date 
[Е, 1981, 1983, 1986]. Описание стандарта SQL приведено в работе Date 
[Е, 1987]. Различные подходы к анализу данных даны в работах Weryard 
[В, 1984], Hawryszkiewycz [Е, 1984] и Ross IF, 1987]. 

Интеграция традиционных СУБД с объектным подходом составляет су¬ 
щность объектно-ориентированных баз данных. Исследования в этом направ¬ 
лении приведены в работах Davis [Н, 1983], Кіш, Lochovsky, [Е, 1989], 
Zdonik, Maier, [Е, 1990]. 

Краткое изложение языка C++ с примерами дано в приложении. 



Глава 11 


Common Lisp Object System. 

Система дешифрования 

Живые организмы способны проявлять очень сложные формы поведения 
на основе мало еще изученных механизмов мышления. Вспомните, как вам 
приходилось планировать маршруты поездок по городу, чтобы выполнить 
массу поручений. Или как в плохо освещенном помещении удается опреде¬ 
лять расположение предметов, чтобы избежать столкновения. Или еще о 
том, как вам удавалось вести беседу с человеком в присутствии множества 
одновременно говорящих людей. Ни одну из таких задач невозможно ре¬ 
шить на основе строгого алгоритма. Планирование маршрута является много¬ 
мерной задачей с вариантами. Передвижение в темноте требует принятия 
решений на основе неполных и размытых (буквально) визуальных данных. 
Выделение речи из множества разговоров требует умения находить полезную 
информацию в условиях шума. Эти и подобные им проблемы решаются 
исследователями в области искусственного интеллекта (ИИ) с целью модели¬ 
рования процессов познания. Создаются интеллектуальные системы, которые 
имитируют некоторые стороны поведения человека. 

Еппап, Lark, Hayes-Roth установили, что «интеллектуальные системы 
отличаются от традиционных рядом признаков, некоторые из которых не яв¬ 
ляются обязательными: 

* Они способны достигать целей, изменяющихся во времени. 

* Они способны сопоставлять, использовать и преобразовывать знания 

* Они справляются с многообразием специальных подсистем, варьируя мето¬ 
ды. 

* Они обеспечивают интеллектуальный интерфейс с пользователем и други¬ 
ми системами. 

* Они сами планируют свои ресурсы и концентрируют их в нужном на¬ 
правлении» [2]. 

Реализация в системе любого из этих требований является непростой 
задачей. Еще сложнее сделать интеллектуальную систему для использования 
в различных прикладных областях (например, для медицинской диагностики 
и диспетчеризации авиарейсов): системы искусственного интеллекта (ИИ) 
редко создаются для общеупотребительного использования. Несмотря на зна¬ 
чительные преувеличения успехов энтузиастов ИИ, работы в этой области 
дали немало хороших практических идей, в частности относительно пред¬ 
ставления знаний, методов решения задач на основе экспертных систем и 
методологий «классной доски». В данной главе рассматриваются подходы к 
созданию интеллектуальной системы для расшифровки криптограмм на осно¬ 
ве метода «классной доски», в значительной степени аналогичного способу 
расшифровки, применяемому человеком. Мы будем иметь повод убедиться, 
что методы OOD хорошо соответствуют этой задаче 1 *. 


** Для решения задачи будем использовать язык CLOS, имея в виду, что CLOS ориентирован 
не столько на задачи ИИ, сколько на задачи связанные, с последовательно-итеративными про¬ 
цессами, что характерно для большинства сложных программных систем. 
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Задача шифрования 

Шифрование «охватывает методы, позволяющие сделать данные непо¬ 
нятными для посторонних» [1 ]. Алгоритмы шифрования преобразуют со¬ 
общения (исходный текст) в шифрованный текст (криптограмму) и наобо¬ 
рот. 

Одним из наиболее известных еще со времен Древнего Рима видов 
шифрования является алгоритм подстановки (замены знаков). При этом 
каждая литера в алфавите исходного текста заменяется другой литерой. 
Например, можно сдвинуть все буквы алфавита: А заменяется на В, 
В — на С, a Z — на А. Тоща следующий исходный текст: 

CLOS is an object-oriented programming language 

превращается в криптограмму: 

DMPT jt bo pckfdu-psjfoufe qsphsbnnjoh mbohvbhf 

Чаще всего замена делается случайным образом, А заменяется на G, 
В — на J и т. д. Возьмем для примера такую криптограмму: 

POG TBCER CQ ТСК AL S NGELCH QZBBR SBAJ G 

Для подсказки уточним, что буква С соответствует букве О исходно¬ 
го текста. Предположим, что для шифрования текста использован алго¬ 
ритм подстановки, что существенно упрощает задачу, в общем случае 
процесс дешифровки не будет столь тривиальным. В процессе расшифров¬ 
ки приходится использовать и метод проб и ошибок, когда мы делаем 
пробное предположение о варианте замены знаков и рассматриваем по¬ 
следствия этого предположения. Можно, например, начать расшифровку с 
предположения о том, что одно- и двухбуквенные слова в криптограмме 
соответствуют наиболее употребительным словам языка (I, a, or, it, in, 
of, on). Подставляя эти буквы в другие слова, мы можем увидеть веро¬ 
ятные значения других литер. Например, если трехбуквенное слово начи¬ 
нается с литеры «о», то это могут быть слова one, our, off. Знание фо¬ 
нетики и грамматики также может способствовать дешифровке. Напри¬ 
мер, следование подряд двух одинаковых литер с малой вероятностью мо¬ 
жет означать «qq*. Наличие в окончании слова буквы «g» позволяет сде¬ 
лать предположение о наличии суффикса «ing*. На еще более высоком 
уровне абстракции логично предположить, что группа слов «it is» более 
вероятна, чем «if is». Необходимо учитывать и структуру предложений, 
которая включает обычно существительные и глаголы. Если выясняется, 
что в предложении есть глагол, но нет существительного с ним связанно¬ 
го, то нужно отвергнуть сделанные ранее предположения и начать новый 
поиск вариантов. Иноща приходится возвращаться в обратном направле¬ 
нии, если сделанное предположение вступает в противоречие с другими 
предположениями. Наша задача: найти систему, которая преобразует 
криптограмму в исходный текст, исходя из предположения о наличии 
простой подстановки литер. 
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11.1. АНАЛИЗ 

Определение границ предметной области 

Выделенный в рамку текст дает описание рассматриваемой предметной 
области, а именно дешифровки криптограмм. В общем случае процесс де¬ 
шифровки является крайне, сложным и неподатливым даже для очень «хит¬ 
рых* методов. Существует, например, стандарт шифрования DES (используе¬ 
мый для шифровки в самых разных областях применения) с глубокой мате¬ 
матической основой, устойчивый ко всем известным методам дешифровки. 
Но наша задача достаточно проста, поскольку мы ограничились методами 
простой замены букв. 

Попробуем решить следующую криптограмму и отметить, как мы это 
делаем (не забегая вперед): 

Q AZWS DSSC KAS DXZNN DASNN 

Для подсказки отметим, что буква W соответствует букве V исходного 
текста. Попытка перебрать все возможные варианты совершенно бессмысле- 
на. Предполагая, что алфавит содержит только 26 прописных английских 
букв, получим 26! (около 4.03 х ІО* 6 ) возможных комбинаций. Следователь¬ 
но, нужно искать обходной метод решения задачи например, использовать 
знания. о структуре слов и предложений и делать правдоподобные допуще¬ 
ния. Как только мы исчерпаем явные решения, мы будем делать вероятные 
предположения и продвигаться дальше. Если обнаружим, что предположение 
приводит к тупику или противоречию, tq вернемся назад и сделаем другую 
попытку. 

Будем отмечать шаги нашего поиска: 

1. Используя подсказку, заменим W на V. 

Q AZVS DSSC KAS DXZNN DASNN 

2. Первое слово из одной буквы, вероятно, А или I, предположим, что 
это А. 


A AZVS DSSC KAS DXZNN DASNN 

3. В третьем слове должны быть гласные звуки и вероятно, что это двой¬ 
ные буквы. Это не может быть UU или II, а также АА (буква А уже 
использована). Попробуем вариант ЕЕ. 

A AZVE DEEC КА Е DXZNN DAENN 

4. Четвертое слово состоит из трех букв и оканчивается на Е, это очень 
похоже на THE. 


A HZVE DEEC THE DXINN DHENN 

5. Во втором слове нужна гласная и для этого подходят I, О, U. Только I 
дает значение, подходящее по смыслу. 


A HIVE DEEC THE DXINN DHENN 
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6. Можно найти несколько слов с двойной буквой Е (DEER,BEER, SEEN). 
Грамматика требует, чтобы третье слово было глаголом, поэтому остано¬ 
вимся на SEEN. 


A HIVE SEEN THE SXJNN SHENN 

7. Смысл в полученном предложении отсутствует, поскольку крапивница 
(HIVE) не может видеть (SEEN), значит, первоначальные предположения 
содержат ошибку. Похоже, что выбор гласной буквы был неверен, и при¬ 
ходится вернуться назад. 

A HAVE SEEN THE SXJNN SHENN 

8. Посмотрим на последнее слово, сдвоенная буква S в конце не дает ос¬ 
мысленного значения и уже использована ранее, а вот LL может иметь 
место. 


A HAVE SEEN THE SXINN SHELL 

9. Последнее слово является частью составного существительного. В качестве 
второй его части по шаблону S? ALL подходит слово SMALL. 

A HAVE SEEN THE SMALL SHELL 

Таким образом, решение найдено. Из процесса решения можно сделать 
три заключения: 

* Применены знания о грамматике, составе слов и чередовании согласных и 
гласных. 

* Сделанные предположения направлялись на ключевое место, а на основе 
знаний строилась цепочка дальнейших рассуждений. 

* Рассуждения во времени менялись. Иногда делались выводы от общего к 
частному (слово из трех букв с окончанием на Е — это THE), а иногда 
от частного к общему (?ЕЕ? может соответствовать DEEF, BEER, SEEN, 
но глагол только SEEN). 

Изложенный подход известен как метод «классной доски». Этот метод 
впервые предложен Ньюэллом (Newell) в 1962 году, а позднее использован 
Рэдди и Эрманом (Reddy, Еппап) в проектах Hearsay, Hearsay II по рас¬ 
познаванию речи [3]. Эффективность этого метода подтвердилась, и метод 
был использован в других областях (выделение сигналов, моделирование мо¬ 
лекулярных объемных структур, распознавание образов и планирование [4]. 
Этот метод показал хорошие результаты для представления декларативных 
знаний и пространственно-временную эффективность в сравнении с другими 
подходами [5]. 

Архитектура, основанная на «классной доске» 

Инглмор и Морган (Englemore, Morgan) для пояснения метода «класс¬ 
ной доски» использовали аналогию составления группой людей изображения 
из фрагментов-вырезок: 

«Вообразим себе комнату с большой классной доской, рядом с 
которой находится группа людей, держащих в руках фрагменты 
большого изображения. Процесс начинают добровольцы, которые 
размещают на доске наиболее характерные фрагменты изображе 
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ния (предположим, что они приклеиваются к доске). Далее каж¬ 
дый участник группы смотрит на оставшиеся у него фрагменты и 
определяет наличие таких, которые подходят к находящимся на 
доске. Участник, нашедший такое соответствие, подходит к доске 
и производит соответствующее изменение. В результате фрагмент 
за фрагментом занимают нужное место по мере подхода к доске 
других участников этого процесса. При этом не существенно, что 
один из участников имеет больше фрагментов, чем другой. Все 
изображение будет полностью собрано без всякого обмена инфор¬ 
мацией между членами группы. Каждый участник активизируется 
самостоятельно и знает, когда ему нужно включиться в процесс. 
Никакого порядка подхода к доске заранее не устанавливается. 
Совместное поведение регулируется только состоянием информации 
на классной доске. Наблюдение за этим процессом демонстрирует 
его ступенчатый характер (по одному фрагменту за подход) и то, 
что оно основано на согласии (согласие на установку очередного 
фрагмента). Это существенно отлично от попытки начать с одного 
из углов и последовательной проверки каждого фрагмента на воз¬ 
можность помещения в соседнем поле» [6]. 

Из рис. 11-1 видно, что основу метода составляют три элемента: класс¬ 
ная доска, совокупность источников знаний и управляющий этими источни¬ 
ками контроллер [7]. Отметим, что последующее определение прямо соот¬ 
ветствует принципам объектного подхода. Нии (Nii) установил: «Классная 
доска нужна для того, чтобы хранить данные о ходе и состоянии решаемой 
задачи, которые (данные) используются и формируются источниками знаний. 
Классная доска объединяет объекты из пространства решений. Эти объекты 
иерархически группируются по уровням анализа и вместе со своими атрибу¬ 
тами образуют словарь пространства решений» [8]. 

Инглмер и Морган уточняют, что «необходимые для решения задачи 
знания о предметной области разделены по нескольким независимым источ¬ 
никам. Каждый источник знаний имеет своей целью сделать информацион¬ 
ный вклад, который приблизит решение задачи. Текущая информация из 
каждого источника помещается на «классной доске» и модифицируется в со¬ 
ответствии с содержанием знаний. Формой представления источников знаний 
являются процедуры, наборы правил или логические заключения» [9]. 

Источники знаний (обозначенные KS) являются зависимыми от пред¬ 
метной области. В системах распознавания речи могут быть сведения о фо¬ 
немах, словах и предложениях. В системах распознавания образов — сведе¬ 
ния о элементарных структурах изображения, таких, как стыки линий или 
участки одинаковой плотности, а на более высоком уровне абстракции об 
объектах, относящихся к конкретной задаче (дома, дороги, поля, автомобили 
и люди). 

В общем случае источники знаний соответствуют иерархической струк¬ 
туре объектов, размещаемых на «классной доске». Более того, каждый ис¬ 
точник оперирует с объектами строго определенных уровней иерархии в ка¬ 
честве источников информации и в качестве получателей сообщений. Напри¬ 
мер, в системе распознавания речи источник знаний о словах должен на¬ 
блюдать за потоком фонем (низкий уровень абстракции), чтобы сформиро¬ 
вать данные о выделенном слове (более высокий уровень абстракции); путем 
фильтрования списка возможных слов (снова более низкий уровень абстрак¬ 
ции) этот источник может проверять гипотезы. 
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Применения 


Источники 

знаний 



Два указанных приема поиска решения называются соответственно пря¬ 
мой и обратной цепью суждений. Прямая цепь суждений позволяет перейти 
от более частных предположений к более общим, а обратная цепь, начина¬ 
ясь от некоторой гипотезы, позволяет проверить эту гипотезу на известных 
предположениях. Вот почему управление на «классной доске» является со¬ 
гласительным, в зависимости от обстоятельств источники знаний могут акти¬ 
визировать либо прямые, либо обратные цепи суждений.^ Источники знаний, 
как правило, состоят из двух компонент-предусловия и действия. 

Предусловие — это состояние «классной доски», которое представляет 
«интерес» для данного источника знаний (способно его активизировать). На¬ 
пример, в распознавании образов предусловием может быть наличие прямо¬ 
линейной области изображения (которая может означать дорогу). Выполне¬ 
ние предусловий заставляет источник знаний сфокусировать внимание на 
конкретном участке «классной доски», а затем привести в действие соответ¬ 
ствующие процедурные правила или знания. 

В этих условиях очередность активизации является излишней: если ис¬ 
точник знаний обнаруживает полезные данные для решения задачи, он дает 
сигнал об этом контроллеру «классной доски». Это напоминает жест рукой, 
указывающий на желание сделать сообщение. Из нескольких источников, де¬ 
лающих такой жест, контроллер выбирает наиболее перспективный с его 
точки зрения и передает ему управление (разрешение на выполнение дейст¬ 
вий). 

Анализ источников знаний 

Вернемся теперь к поставленной задаче и подумаем, какие источники 
знаний будут полезны для ее решения. Наиболее часто инженеры знаний в 
такой ситуации просто садятся рядом с экспертом по предметной области и 
начинают выявлять приемы (эвристики), применяемые экспертом при реше¬ 
нии аналогичных задач. В нашем случае для этого придется расшифровать 
некоторое количество криптограмм и отметить особенности процесса поиска 
решения. 

В результате выявляется тринадцать источников знаний, относящихся к 
проблеме, которые приведены в списке: 
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* Общие приставки 

* Общие суффиксы 

* Согласные буквы 

* Прямая подстановка 

* Сдвоенные буквы 

* Частота букв 

* Правильные строки 

* Проверка по шаблону 

* Структура предложения 

* Короткие слова 

* Решение 

* Гласные буквы 

* Структура слова 


Наиболее частое начало слов (например, ге, 
anti, un). 

Наиболее частое окончание слов (ly, ing, es, 
ed). 

Буквы не являющиеся гласными. 

Подсказки, как часть выражения. 

Наиболее часто сдваиваемые буквы (tt, 11, ss). 
Вероятность появления букв в тексте. 
Допустимые и недопустимые сочетания букв 
(например, qu и zg). 

Слова соответствующие шаблону. 

Грамматика, включая значения существительных 
и глаголов. 

Варианты одно-, двух-, трех- и четырехбуквен¬ 
ных слов. 

Найдено ли решение или имеет место тупик. 
Буквы не являющиеся согласными. 

Расположение гласных и общая структура суще¬ 
ствительных, глаголов, прилагательных, наречий, 
приставок, союзов и т.д. 


Исходя из объектно-ориентированного подхода, все эти источники явля¬ 
ются потенциальными классами, объекты которых имеют состояние (знания), 
характеризуются поведением (знание суффикса может влиять на значение 
слова) и обладают индивидуальностью (знания о коротких словах независи¬ 
мы от проверки по шаблону). 

Можно установить иерархию указанных источников знаний. В частно¬ 
сти, существует группы источников знаний о предложениях, о словах, о 
группах букв и об отдельных буквах. Такая иерархия соответствует объек¬ 
там, выносимым на «классную доску»: предложения, слова, строки и буквы. 


11.2. ПРОЕКТИРОВАНИЕ 
Проектирование «классной доски» 

Теперь у нас есть все, чтобы приступить к решению поставленной за¬ 
дачи с использованием метода «классной доски». Это классический пример 
повторного использования метода решения на уровне проекта. Метод «класс¬ 
ной доски» предполагает, что среди объектов верхнего уровня системы име¬ 
ют место: классная доска, несколько источников знаний и контроллер. Оста¬ 
ется только определить классы и объекты предметной области, которые спе¬ 
циализируют эти, наиболее общие, абстракции. 

Объекты классной доски. Объекты образующие содержание классной 
доски, отвечают трем уровням абстракции знаний и образуют три следую¬ 
щих класса: 


sentence 


Полная криптограмма 
Отдельное слово в криптограмме 
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Применения 


* cipher-letter Отдельная буква в слове 

Источники знаний должны пользоваться общей информацией о сделан¬ 
ных в процессе решения предположениях, поэтому в число объектов класс¬ 
ной доски включается следующий класс: 

* assumption Сделанные предположения (допущения) 

Необходимо также знать полный буквенный алфавит, используемый в 
тексте и криптограмме, что дает последний класс: 

* alphabet Алфавит текста, алфавит криптограммы и их 

соотношение 

Есть ли между этими пятью классами что-то общее? Ответ утверди¬ 
тельный: все они соответствуют объектам классной доски и существенно от¬ 
личны от других объектов (например, от контроллера). Поэтому вводится 
следующий суперкласс для всех этих объектов: 

(defclass blackboard-object О) 

С точки зрения внешнего поведения определим для этого класса две 
операции: 

* add-object Добавить объект на классной доске 

* remove-object Удалить объект с доски 

Зависимости и документация. Предложения, слова и буквы также свя¬ 
заны определенной общностью: все они зависят от конкретного источника 
знаний и должны уметь обращаться к этим источникам. Источники знаний 
в свою очередь должны получать информацию об изменениях соответствую¬ 
щих объектов. Это напоминает механизм зависимостей языка Smalltalk, ис¬ 
пользованный в гл. 9. Итак, запишем: 

(defclass dependent О 

((the-reference :accessor reference))) 


Для этого класса (dependent) определен всего один слот the-reference, 
обозначающий список источников знаний, связанных с данным объектом. К 
числу операций данного класса относятся: 


* add dependency 

* remove-dependency 

* dependency-p 

* each-dependency 


Добавляет ссылку на источник знаний 
Удаляет ссылку на источник знаний 
Селектор: определяет зависимость объекта от 
заданного источника знаний 
Итератор: проверка всех зависимостей 


Использован стиль именования предикатов языка CLOS (например, 
dependency-p) за счет суффикса -р. Зависимость является особым свойством, 
которое может примешиваться к другим классам. Например, буква является 
объектом классной доски и зависимостью, что позволяет смешать два этих 
класса для получения нужного поведения. Механизм смешения увеличивает 
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возможность повторного использования классов и сохраняет их независимость 
в процессе проектирования. 

Буквы имеют общие свойства с алфавитом: объекты этих классов могут 
иметь взаимные отношения и допущения. Так, некоторый источник знаний 
может допустить, что буква «к» в шифре соответствует букве «р» исходного 
текста. Поэтому введен еще один класс-смесь: 

(defclass assumable-object О) 

В нашей системе предположения имеют место только в отношении от¬ 
дельных букв, но не о словах и предложениях. Можно, например, предполо¬ 
жить, что какая-либо буква шифра соответствует некоторой букве алфавита. 
Но алфавит состоит из множества букв, каждая из которых может быть по¬ 
ставлена в однозначное соответствие с шифром. Это отличие букв шифра от 
букв алфавита объясняет отсутствие слотов в кассе assumable-object; слоты 
появятся при определении производных классов. Следовательно, класс 
assumable-object служит исключительно для определения группы общих опе¬ 
раций, которые будут реализованы в производных подклассах. Определим 
следующий набор операций для экземпляров этого класса: 

* state assumption Сделать допущение 

* retract-assumption Отменить допущение 

* plain-assoc Вернуть шифрованный эквивалент для заданной 

буквы текста 

ф cipher-assoc Вернуть текстовый эквивалент для заданной 

буквы шифра 

* plain-letter-defined-p Селектор: определена ли заданная буква текста? 

* cipher-letter-defined-p Селектор: определена ли заданная буква шиф¬ 

ра? 

* plain-letter-asserted-p Селектор: найдено ли значение для данной бук¬ 

вы текста? 

* cipher-letter-asserted-p Селектор: найдено ли значение для данной бук¬ 

вы шифра? 

Из приведенного описания видно, что установлено два вида соотноше¬ 
ний шифр-текст: одно—временное определение и другое — окончательно до¬ 
казанное значение. По мере расшифровки криптограммы может делаться 
множество различных предположений о соотношении букв шифра и текста, 
но в конце концов находятся окончательные значения такого соотношения 
для всего алфавита. Этот подход находит явное выражение в описании 
классов. Сначала определяем класс assumption: 

(defclass assumption (blackboard-object) 

((the-knowledge-source :accessor the-knowledge-source 

:initang :the-knowledge-source) 

(the-reason :accessor the-reason 

:initang :the-reason) 

(the-plain-letter :accessor the-plain-letter 

:initang : the-plain-letter) 

(the-dpher-letter :accessor the-cipher-letter 

:initang :the-cipher-letter) 

(the-assumable-objects :accessor the-assumable-objects))) 






Примет 


Этот класс является объектом «классной доски», поскольку информация 
о сделанных предположениях используется всеми источниками знаний. От¬ 
дельные слоты означают следующие свойства: 

* the-knowlege-source Источник знаний, из которого исходит сделан¬ 

ное предположение 

* the-reason Основание для сделанного предположения 

* the-plain-letter Буква исходного текста, для которой сделано 

предположение 

* the-cipher-letter Предполагаемое значение шифра для буквы ис¬ 

ходного текста 

* the-assumable-objects Объекты «классной доски», которые затрагивают 

сделанное предположение 

Необходимость каждого из приведенных слотов в значительной степени 
объясняется природой предположений: какой-либо источник знаний формиру¬ 
ет предполагаемое соотношение буква-шифр на основании определенных 
причин (обычно путем реализации некоторого правила). Назначение послед¬ 
него слота (the-assumable-object) менее очевидно. Его необходимость вызвана 
возможностью возникновения обратных цепочек суждений. Если сделанное 
предположение не подтвердится, то нужно соответственно изменить состоя¬ 
ние объектов, которые воспользовались сделанным ранее предположением 
(через механизм зависимости). Далее определим подкласс assertion: 

(defdass assertion (assumption) 

О) 

Общим для классов assumption и asertion являются следующие опера¬ 
ции: 

* state-assumption Сделать допущение 

* retract-assumption Отвергнуть допущение 

* retractable-p Селектор: является ли допущение временным? 

Для всех сделанных предположений (допущений) значение предиката 
retractable является истинным, а для доказанных окончательно ложным. До¬ 
казанное предположение уже нельзя изменить или отвергнуть. 

Проектирование объектов «классной доски». Необходимо теперь ввести 
в проект классы для предложения (sentence), слова (word), буквы шифра 
(cipher-letter) и алфавита (alphabet). Предложение — это объект «классной 
доски», содержащий список слов, составляющих данную фразу. Исходя из 
этого, запишем: 

(defclass sentence (blackboard-object dependent) 

((the-words :accessor the-words))) 

В дополнение к операциям add-object и remove-object (определенным в 
суперклассе blackboard-object) и четырем операциям, унаследованным от 
класса dependent, добавлено еще две следующие: 

* sentence-value Текущее значение предложения 
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* solved-p Имеет значение true (истина), если все слова в 

предложении полностью расшифрованы 

Первоначально sentence-value совпадает с текстом криптограммы. А ког¬ 
да значение solved-p станет истинным, то с помощью операции sentence- 
value можно прочесть исходный (расшифрованный) текст. Слово также явля¬ 
ется объектом «классной доски», включая свойства зависимости, и состоит 
из последовательности букв. Для удобства оперирования источниками знаний 
в класс введены указатели от слова на соответствующее предложение, а 
также на предыдущее и последующее слова в данном предложении. Описа¬ 
ние класса word выглядит так: 


:accessor the-sentence 


(the-prevtous-word 

(the-next-word 


dnitarg :the-sentence) 
:accessor the-previous-word) 
:accessor the-next-word 
dnitarg :the-next-word))) 


Так же как для предложения, в этот класс введены две дополнитель- 


* word-value Текущее значение слова 

* solved-p Имеет значение true (истина), если определены 

окончательно все буквы в данном слове 

Теперь можно определить класс cipher-letter (буква шифра). Объекты 
этого класса относятся к «классной доске», являются предполагаемым и об¬ 
ладают свойством зависимости. Помимо этих свойств, такие объекты имеют 
значение (например, «Н») и список возможных способов соотнесения с бук¬ 
вами исходного текста. Опишем это следующим образом: 

(defclass cipher-letter (blackboard-object assumable-object dependent) 

((the-word : accessor the-word 

:initarg :the-word) 

(the-clpher-letter :accessor the-cipher-letter 

:initarg :the-dpher-letter) 

(the-plain-assumptions taccessor the-plain-assumptions))) 

Слот с именем the-plain-assumption может содержать множество объек¬ 
тов, предполагаемых в качестве букв исходного текста. Это позволяет источ¬ 
никам знаний на основании предыстории сделанных и отвергнутых предпо¬ 
ложений избежать дальнейших ошибок. 

В этот класс введена только одна дополнительная операция: 

* letter-value Текущее значение буквы 

Необходимо помнить также о восьми операциях суперкласса assumable- 
object. Теперь обратимся к классу alphabet (алфавит). Этот класс содержит 
данные об алфавите исходного текста и шифра, а также о взаимосоответст- 
вии между ними. Это необходимо, чтобы источники знаний могли получить 
информацию о выявленных соответствиях между буквами шифра и текста и 
тех, которые еще предстоит найти. Например, если уже доказано, что буква 
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«С» в шифре соответствует букве «М» текста, то этот факт фиксируется в 
алфавите и источники знаний уже не будут делать других предположений в 
отношении буквы «М». Для эффективности обработки полезно иметь воз¬ 
можность получать данные о взаимосоответствии букв шифра и текста дву¬ 
мя способами: по букве шифра и по букве исходного текста. Определим 
класс alphabet следующим образом: 

(defclass alphabet (blackboard-object assumable-object) 

<(the-plalntext-map :accessor the-plaintext-map) 

(the-ciphertext-map raccessor the-ciphertext-map))) 

В отношении класса cipher-letter необходимо переопределить операции 
суперкласса assumable-oject, чтобы использовать их применительно к алфави¬ 
ту. Определим теперь класс «классная доска», который состоит из пяти опи¬ 
санных ранее классов: 


(defclass blackboard О 
((the-assumptions 

(the-sentence 

(the-words 

(the-letter 

(alphabet 


:accessor the-assumptions) 

:accessor the-sentence) 
taccessor the-words) 

:accessor the-letter) 

:accessor the-alphabet 

:initform (make-instance ’alphabet)))) 


Для большинства слотов не определяются квалификаторы :initarg и 
:initform, поскольку в начальный момент «классная доска» не содержит ни¬ 
каких предположений, предложений, слов и букв. Однако в исходном состо¬ 
янии «классная доска» содержит алфавит (без данных о соответствии шифр- 
тексту), чем определяется наличие квалифакатора :initform в последнем сло¬ 
те. Класс blackboard содержит операции state-assumption и retract-assumption, 
которые реализуются для всех экземпляров класса assumption, а также опе¬ 
рации add-object и remove-object от класса blackboard-object. Определим еще 
пять операций, специфичных для «классной доски»: 



Рис. 11-2. Диаграмма классов «классной доски». 
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* reset 

* assert-problem 

* solved-p 

* retrieve-solution 

* connect 


Очистка «классной доски» 

Помещение на доске содержания задачи 
Имеет значение true (истина), если предложе¬ 
ние расшифровано 
Значение исходного текста 
Разрешение доступа к доске источника знаний 


Последняя операция устанавливает дисциплину связи «классной доски» с 
источниками знаний. На рис. 11-2 приведена итоговая диаграмма классов, 
связанных с классом blackboard. Эта диаграмма в первую очередь отражает 
отношения наследования. Отношения использования для простоты опущены 
(например, между assumption и assumable-object). 

Проектирование источников знаний 
В предыдущем разделе мы выделили тринадцать источников знаний, от¬ 
носящихся к решаемой задаче. Теперь можно приступить к проектированию 
структур классов для этих видов знаний (как это было сделано для «класс¬ 
ной доски») и обобщить их в более абстрактные классы. 

Проектирование специализированных источников знаний. Предположим, 
что существует абстрактный класс knowlege-source (по аналогии с классом 
blackboard-object). Но, прежде чем определять все тринадцать источников в 
качестве подклассов одного общего суперкласса, нужно посмотреть не обра¬ 
зуют ли знания группы из нескольких источников (кластеры). Действитель¬ 
но, такие группы имеют место: некоторые источники знаний оперирует це¬ 
лым предложением, другими — словами, фрагментами слов или отдельными 
буквами. Отразим этот факт в следующих определениях: 


(defclass sentence-knowledge-source (knowledge-source) 
О) 

(defclass word-knowledge-source (knowledge-source) 

0) 

(defclass string-knowledge-source (knowledge-source) 

0) 

(defclass letter-knowledge-source (knowledge-source) 
(0) 


Для каждого из приведенных абстрактных классов можно создать спе¬ 
цифические подклассы. Подклассы от класса sentence-knowledge-source будут 
следующими: 

(defclass sentence-structure-knowledge-source (sentence-knowledge-source) 

О) 

(defclass solved-knowledge-source (sentence-knowledge-source) 

0) 


А для класса word-knowledge-source следующими: 

(defclass word-structure-knowledge-source (word-knowledge-source) 

0) 

(defclass small-word-knowledge-source (word-knowledge-source) 

0) 

(defclass pattem-matching-knowledge-source (word-knowledge-source pattern-matcher) 
0) 
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Последний класс требует некоторых пояснений. Ранее упоминалось, что 
цель такого класса состоит в проверке вариантов .слов по шаблону. Для 
описания шаблона можно воспользоваться обозначениями, принятыми в опе¬ 
рационной системе Unix: 

* Любой элемент ? 

* Отсутствие элемента - 

* Несколько элементов * 

* Начало группы { 

* Конец группы } 

С помощью этих символов покажем пример шаблона для данного клас¬ 
са ?E~{AEIOU}, означающий слово из трех букв, начинающееся с любой 
буквы, далее следует буква Е и, наконец, любая буква, кроме гласных А, 
Е, I, О, U. Поскольку проверка по шаблону является методом полезным 
как для данной системы в целом, так и в других областях приложения, со¬ 
ответствующий класс целесообразно выполнять в качестве смешиваемого, а 
не относить к одному из источников знаний. По тем же причинам класс 
pattern-matcher целесообразно выполнить в виде подкласса от более общего 
класса dictionary (словарь). Словарь является объектом для помещения в не¬ 
го слов, которые можно извлекать из словаря непосредственно, но объект 
pattern-matcher позволяет находить нужные слова путем фильтрации по за¬ 
данному шаблону. Зафиксируем принятые решения в следующих определе¬ 
ниях: 

(defclass dictionary О 

О) 

(defclass pattern-matcher (dictionary) 

О) 

Слоты этих двух классов не приведены, поскольку в данном случае это 
не существенно. Словарь следует рассматривать как список слов или поток 
с произвольным доступом — в любом случае поведение экземпляров данного 
класса одинаково. Продолжим определение подклассов для класса string- 
knowledge-source: 

(defclass common-prefix-knowledge-source (string-knowledge-source) 

О) 

(defclass common-suffix-knowledge-source (string-knowledge-source) 

0) 

(defclass double-letter-knowledge-source (string-knowiedge-source) 

0) 

(defclass legal-string-knowledge-source (string-knowledge-source) 

0) 

И наконец, определим подклассы для класса letter-knowledge-source: 

(defclass direct-substitution-knowledge-source (letter-knowledge-source) 

О) 

(defclass vowel-knowledge-source (letter-knowledge-source) 

0) 

(defclass consonant-knowledge-source (letter-knowledge-source) 

0) 

(defclass letter-frequency-knowledge-source (letter-knowledge-source) 

0) 
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Обобщение источников знаний. Для всех упомянутых специализирован¬ 
ных классов определены только две операции: 

* reset Повторный запуск источника знаний 

* evaluate-blackboard Определение состояния «классной доски» 

Причина столь упрощенного интерфейса в относительной автономности 
знаний: мы указываем на интересующий объект «классной доски* и даем 
команду выполнить соответствующие правила по оценке состояния всей до¬ 
ски в целом. При выполнении правил оценки каждый из источников знаний 
может осуществить следующие действия: 

* Сделать предположение относительно истинного значения одной из букв 
шифра. 

* Найти противоречие в отношении ранее сделанных предположений и от¬ 
клонить такие предположения. 

* Доказать правильность какого-либо предположения. 

* Сообщить контроллеру о наличии полезной информации для вынесения на 
доску. 

Все эти действия являются общими для всех источников знаний. Вооб¬ 
ще говоря, все приведенные операции образуют механизм вывода заключе¬ 
ний. Определим механизм вывода как объект, который на основании извест¬ 
ных правил либо производит действия согласно правилам для перехода к 
новым правилам (прямая цепь), либо принимает решение по выдвинутым 
ранее гипотезам (обратная цепь). На основании сказанного введен следую¬ 
щий класс: 

(defclass inference-engine О 

((the-rules :accessos the-rules :initarg :the-rules))) 

Слот, определенный в этом классе, включает в себя все правила меха¬ 
низма вывода. Лишь одна операция определена первично в этом классе — 
(evaluate-rubs) обработка правил механизма вывода. Таким образом, основ¬ 
ная цель специализированных источников знаний состоит в возможности 
хранить соответствующие правила. Операция evaluate-blackboard в первую 
очередь обращается к методу evaluate-rules, а затем переходит к выполне¬ 
нию одной из четырех упомянутых выше операций. 

Что такое правило? Для иллюстрации приведем следующее правило, ка¬ 
сающееся знаний о суффиксах: 

? ’ ((• і ? ?) 

(• і N G) 

(* I Е S) 

С I Е D) 

Это правило означает, что заданному шаблону для строки букв *1?? 
(условие) могут соответствовать суффиксы ING, IES и IDE (заключение). 
На основании этого можно определить класс для представления правил: 

(defclass rule О 

((the-antecedent :accessor the-antecedent) 

(the-consequent :accessor the-consequent))) 

С точки зрения строения данного класса можно утверждать, что источ¬ 
ники знаний являются разновидностью механизма вывода. А с точки зрения 
25 Гради Буч 
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зависимости источников знаний от объектов на «классной доске» можно ут¬ 
верждать, что источники знаний обладают качеством зависимости. Поэтому 
механизм зависимости вводится в источники знаний по аналогии с объекта¬ 
ми «классной доски». 

Определим это следующим образом: 

(defdass knowledge-source (inference-engine dependent) 

((the-blackboard :accessor the-black board) 

(the-controller :accessor the-controller) 

(the-assumptions :accessor the-assumptions))) 

В этом классе имеются слоты the-blackboard и the-controller для связи с 
объектами системы. Слот the-assumption необходим для хранения информа¬ 
ции о последовательности сделанных предположений, чтобы избежать повто¬ 
рения и учесть ошибки. 

Экземпляры класса blackboard содержат в себе объекты «классной до¬ 
ски». Необходимо ввести класс knowledge-source, охватывающий перечень 
всех источников знаний, относящихся к решаемой задаче. На основании 
сказанного запишем: 



Рис. 11-3. Диаграмма классов для источников знаний. 
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Рис. 11-4. Механизм контроллера. 

(defclass knowledge-sources О 

((the-knowledge-sources :accessor the-knowledge-sources 

:initform (make-knowledge-sources)))) 

Наличие квалификатора :initform объясняется тем, что при создании 
объекта класса knowledge-source создается 13 объектов специализированных 
источников знаний. Для класса knowledge-source определяются три операции: 

* restart Перезапуск источника знаний 

* start-knowledge-sources Установка начальных значений условий для 

каждого из источников знаний 

* connect Установление связи источника знаний с «класс¬ 

ной доской* или с контроллером 

На рис. 11-3 показана структура классов для созданных в процессе 
проектирования классов knowledge-source. 

Проектирование контроллера 

На рис. 11-4 показано взаимодействие контроллера с отдельными источ¬ 
никами знаний. В процессе поэтапной расшифровки криптограммы отдельные 
источники знаний могут выявлять полезную информацию для сообщения 
контроллеру. И наоборот, может быть обнаружено, что ранее переданная 
информация оказалась ложной и ее надо устранить. Поскольку все источни¬ 
ки знаний имеют равные права, контроллер должен выбрать из них тот, 
информация которого может оказаться наиболее полезной, и активизировать 
его вызовом операции evaluate-blackboard. 

Как определяет контроллер, какой из источников знаний следует акти¬ 
визировать? Можно предложить несколько полезных правил: 

* Больший приоритет имеет окончательное утверждение перед допущением. 

* Наибольший вес имеет информация источника, отвечающего за всю фра¬ 
зу. 

* Проверка по шаблону более приоритетна, чем обработка структуры пред¬ 
ложения. 

Сообщение контроллеру можно реализовать в классе, определенном для 
зависимостей. Однако в виду наличия приоритетов сообщений лучше образо¬ 
вать соответствующий подкласс: 

(defclass ordered-dependent (dependent) 

О) 

Объекты нового класса почти такие же, как объекты класса dependent, 
но операция add-dependency выполняется согласно приоритетам. Теперь 
можно определить интерфейс для класса, означающего контроллер: 
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(defclass controller О 

((the-hints :accessor the-hints) 

(the-knowledge-sources :accessor the-knowledge-sources))) 

Слот с именем the-hints означает объект класса ordered-dependent. Для 
объекта-контроллера определяется семь операций: 

* reset Перезапуск контроллера 

* add-hint Добавить данные от источника знаний 

* remove-hint Удалить данные от источника знаний 

* process-next-hint Найти данные с наибольшим приоритетом 

* solved-p Селектор: имеет значение true (истина), если 

задача решена 

* unable-to-procesed-p Селектор: имеет значение true (истина), если 

источник знаний зашел в тупик 

* connect Устанавливает связь контроллера с источником 

знаний 

11.3. ОБЪЕДИНЕНИЕ В СИСТЕМУ 
Объединение элементов «классной доски» 

Теперь, когда ключевые абстракции предметной области выявлены, 
можно приступить к их соединению в действующую систему. Поскольку 
CLOS не является строго типированным языком, допустимо (и желательно) 
вести разработку элементов системы последовательно-итеративно. Мы будем 
реализовывать и проверять компоненты системы по отдельности. 

Объединение объектов верхнего уровня. На рис. 11-5 показана диаг¬ 
рамма объектов нашей системы на самом верхнем уровне, которая полно¬ 
стью соответствует структуре метода «классной доски», приведенной на 
рис. 11-1. В качестве класса, отвечающего данному проектному решению, 
используем следующий класс, названный cryptographer: 

(defclass cryptogrpher О 

( (the-blackboard :accessor the-blackboard 

:initform (make-instance ’blackboard)) 

(the-knowledge-sources taccessor the-knowledge-sources 

:initform (make-instance ’knowledge-source)) 

(the-controller taccessor the-controller 

dnitform (make-instance ’controller)))) 

Для всех слотов этого класса использован квалификатор :initform для 
инициализации всех составляющих класс объектов. Мы отказались от ис¬ 
пользования в слотах квалификатора :type, хотя тип всех слотов известен, 
потому, что квалификатор :initform гарантирует нас от возможных ошибок. 
Кроме того, в языке CLOS контроль соответствия типов выполняется только 
во время исполнения программы. 

Для введенного класса определяются три исходных операции: 

* initialize-intance Объединение «классной доски», источников зна¬ 

ний и контроллера в общий объект 

* restart Повторный запуск задачи 

* decipher Процесс дешифровки заданной криптограммы 

Для стиля программирования CLOS характерно определять функцию, 
которая генерирует объекты класса cryptographer. Определим ее так: 
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Рис. 11-5. Диаграмма объектов для задачи дешифровки. 


(defun create-cryptographer О 

(defvar ‘cryptographer* (make-instance ’cryptographer))) 

Вызов этой функции создает переменную ‘cryptographer*, которая озна¬ 
чает экземпляр класса cryptographer. Использование макроопределения .defvar 
объясняется тем, что переменная ‘cryptographer* должна определяться в ка¬ 
честве глобальной. 

В процессе инициализации объекта реализуются связи между «классной 
доской» и источниками знаний, а также между источниками знаний и конт¬ 
роллером. Операцию initialize-instance нет необходимости вызывать специаль¬ 
но, поскольку она относится к разряду первичных методов и вызывается ав¬ 
томатически с помощью make-instance. Поэтому лучше всего определять свя¬ 
зи между элементами системы с помощью квалификатора rafter в методе 
initialize-instance следующим образом: 

(defmethod initiaize-instance :after ((application cryptographer)) 

(connect (the-blackboard application) (the-knowledge-sources application)) 

(connect (the-knowledge-sources application) (the-controiler application)) 

Обратим внимание на способ применения методов доступа к слотам ос¬ 
новного объекта. Метод reset предельно прост: его цель — вернуть в исход¬ 
ное состояние все слоты объекта: 

(defmethod reset ((application cryptographer)) 

(reset (the-blackboard application) 

(reset (the-knowledge-sources application) 

(reset (the-controiler application)) 


Уточним, что метод decipher принимает строку в качестве исходной 
криптограммы. Это позволяет выполнить механизм дешифровки независимо 
от способа ввода задания; для нас желательно создавать обобщенные меха¬ 
низмы решения, не отвлекаясь на специфику конкретного задания. Теперь 
мы можем определить основную функцию нашей задачи по дешифровке: 
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(defun decode О 

(reset ‘cryptographer*) 

(format t "-AEnter the ciphertext ->") 

(let ((plaintext (decipher ‘cryptographer* (string-upcase (read-line)»» 

((equal ""plaintext) 

(format t "-AUnable todecode the ciphertext") 

0) 

(t 

(format t"~APlaintext -> -a” plaintext) 

0 ») 

Для объявления локальной переменной plaintext использована форма 
оператора let, позволяющего возвращать значение, получаемое методом 
decipher. Для упрощения операций с источниками знаний выполняется пре¬ 
образование исходной строки шифра к верхнему регистру алфавита. 

Метод decipher несколько сложнее. В первую очередь с помощью мето¬ 
да assert-problem задание помещается на «классную доску». После этого ак¬ 
тивизируются источники знаний. И наконец, начинается циклический про¬ 
цесс обращения источников знаний к контроллеру с новыми и новыми пред¬ 
положениями и выводами до тех пор, пока не будет найдено решение зада¬ 
чи, либо до исчерпания источников знаний. В тексте программы это будет 
выглядеть так: 

(defmethod decipher ((application cryptographer) ciphertext) 

(check-type ciphertext string) 

(let ((controller (the-controller application))) 

(assert-problem (the-blackboard application) ciphertext) 

(start-knowledge-sources (the-knowledge-sources application)) 

(when (unable-to-proceed-p controller) (return"”)) 

(when (solved-p controller (return (retrieve-solution controller)» 
(process-next-hint controller))») 

В приведенном методе имеются два аргумента с именами application и 
ciphertext. Первый аргумент для отличия квалифицирован классом 
cryptographer. Поскольку этот метод не является множественным (имея вви¬ 
ду, что он отличается не только аргументом), мы не квалифицируем второй 
аргумент, хотя для надежности следует проверить его тип. 

Теперь посмотрим внимательно на один из методов «классной доски» и 
на один из методов контроллера, а именно assert-problem и retrieve-solution. 

Метод assert-problem интересен тем, что он создает структуру объектов 
«классной доски». По ранее указанным причинам обрабатывать строку удоб¬ 
нее справа налево. Используя псевдокод, опишем наш алгоритм следующим 
образом: 

;; убираем из строки все пробелы в начале и в конце 

;; если получилась пустая строка, то возврат 

;; создаем объект-предложение 

;; выносим предложение на доску 

;; создаем объект-слово (самое крайнее справа) 

;; добавляем слово к предложению 
;; выносим слово на доску 

;; циклически для каждого символа справа-налево 
;; если пробел 

;; делаем следующее слово текущим 

;; создаем объект-слово 
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;; добавляем слово к предложению 

;; выносим слово на доску 

;; создаем объект-букву шифра 

;; добавляем букву к слову 

;; выносим букву на доску 

На языке CLOS этот алгоритм будет выражен следующим образом: 

(defmethod assert-problem < (the-blackboard blackboard)(ciphertext)) 

(check-type ciphertext string) 

(let ((the-string (string-trim ’(#\space) ciphertext)) 

(current-word 0) 

(next-word 0) 

(current-letter 0) 

(when (string-equal ""the-string) (retum-from assert-problem nil)) 

(setf (the-sentence the-blackboard) (make-instance ’sentence)) 

(serf current-word 

(make-instance 'word 

:the-sentence (the-sentence the-blackboard) 

:the-next-word next-word)) 

(push current-word (the-words (the-sentence the-blackboard))) 

(push current-word (the-words (the-blackboard)) 

(dotimes (index (length the-string) t) 

(let ((the-character 

char the-string (— (— (length the-string) 1) index)))) 

(if (eq ’#\space the-character) 

(and (setf next-word current-word) 

(setf current-word) 

(make-instance ’word 

:the-sentence (thesentence the-blackboard) 
:the-next-word next-word)) 

(setf (the-previous-word next-word) current-word) 

(push current-word 

(the-words (the-sentence the-blackboard))) 

(push current-word (the-words the-blackboard))) 

(and (setf current-letter 

(make-instance ’cipher-letter 
:the-word current-word 
:the-cipher-letter the-character)) 

(push current-letter (the-letters current-word)) 

(push current-letter (the-letters the-blackboard)))))) 
t)) 

Метод assert-problem, подобно методу decipher, не является множествен¬ 
ным, поэтому в нем квалифицируется только первый аргумент. Гораздо про¬ 
ще выглядит метод retrieve-solution, который только возвращает текст пред¬ 
ложения: 

(defmethod retrieve-solution ((the-blackboard blackboard)) 

(sentence-value (the-sentence Ihe-blackboard))) 

Чуть сложнее метод sentence-value, который формирует предложение из 
слов разделенных пробелами: 

(defmethod sentence-value ((the-sentence)) 

(let ((the-string ())) 

(dolist (а -word (the-words the-sentence) t) 

(setf the-string 
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(concatenate ’string the-string (word-value a-word) »))) 

(string-right-trim ’#space) the-string))) 

Аналогичным образом метод word-value создает слово из отдельных 
букв: 

(defmethod word-value ((the-word word)) 

(let ((the-string ())) 

(dolist (а -letter (the-letters the-word) t) 

(push (letter-value а -letter) the-string)) 

(reverse coeroe the-string’string)))) 

Еще несколько сложнее метод letter-value. Он возвращает значение са¬ 
мого последнего предположения, сделанного относительно данной буквы (ес¬ 
ли таковые имеются), либо исходное значение этой буквы: 

(defmethod letter-value < (the-letter cipher-letter)) 

(if (null (the-plain-assumptions the-letter)) 

(the-cipher-letter the-letter) 

(the-plain-letter (first (the-plain-assumptions the-letter))))) 

Реализация механизма выдвижения предположений. Нам нужно создать 
механизм, который формирует и отменяет значения элементов, имеющихся 
на «классной доске». Но сначала рассмотрим механизм выдвижения предпо¬ 
ложений об этих значениях. Этот механизм интересен ввиду его динамично¬ 
сти. В процессе поиска решения предположения непрерывно создаются и 
разрушаются. 

На рис. 11-6 показаны главные потоки управления в процессе выдвиже¬ 
ния предположений. Источник знаний сообщает о ..имеющихся предположени¬ 
ях «классной доске», которая определяет к каким элементам это предполо¬ 
жение относится. 

Полезно посмотреть на этот механизм прежде всего в отношении наи¬ 
более специфичных объектов. Предположение относительно буквы шифра ре¬ 
ализуется предельно просто, путем занесения его в соответствующий список 
предположений. Это выглядит следующим образом: 



Рис. 11-6. Механизм выдвижения предположений. 
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(defmethod state-assumption (the-assumption (the-object cipher-letter)) 
(check-type the-assumption assumption) 

(push the-assumption (the-assumption the-object)) 


Этот метод отличается только по второму аргументу, поэтому первый 
аргумент неквалифицирован. Для класса assumption логика задачи требует 
хранения данных о всех объектах, связанных с выдвинутыми предположени¬ 
ями. Для этой цели служит слот the-assumable-objects. Например, если сде¬ 
лано предположение о какой-либо букве шифра, то эта буква включается в 
список объектов-предположений. Поскольку предположения могут быть связа¬ 
ны с алфавитом, можно ввести в класс assumable-object обобщенный метод с 
квалификатором :after в следующем виде: 

(defmethod state-assumption :after (the-assumption (the-object assumable-object)) 

(push the-object (the-assumable-object the-assumption))) 

Это хороший пример использования метода с квалификатором: если не¬ 
которая группа операций в обобщенной функции может оказаться связанной 
либо с более общим, либо с более специализированным классом, то эти 
операции целесообразно снабдить одним из квалификаторов :after, :before 
или :around. 

Что если допущение в отношении какой-либо буквы уже доказано? В 
этом случае следует прекратить выдвижение новых предположений. Чтобы 
остановить любые действия, которые могут изменить существующее состоя¬ 
ние, определим следующий метод с квалификатором :around: 

(defmethod state-assumption taround (the-assumption (the-object cipher-letter)) 

(if plain-letter-asserted-p the-object (the-plain-letter the-assumption)) 
nil 

(call-next-method))) 

Квалификатор :around в отличие от :before позволяет принять решение 
о том, следует ли вообще вызывать основной метод (с помощью call-next- 
method). Приведенный выше метод в случае окончательного доказательства 
значения буквы возвращает значение nil. Можно переопределить метод 
plain-letter-asserted-p так, чтобы он не предшествовал всем объектам-предпо¬ 
ложениям. Для класса cipher-letter, в частности, определим его реализацию 
так: 

(defmethod plain-letter-asserted-p ((the-object cipher-letter) the-letter) 

(check-type the-letter character) 

(and (not (null (the-plain-assumptions the-object») 

(not (retractable-p (first (the-plain-assumptions the-object)))))) 

Этот метод возвращает значение true (истина), только если существуют 
какие-либо предположения и последнее из них не является доказанным. Те¬ 
перь нужно уточнить метод retractable-p для классов assumption и assertion: 

(defmethod retractable-p ((the-assumption assumption)) 
t) 

(defmethod retractable-p ((the-assumption assumption)) 
nil) 


Выдвижение предположений относительно алфавита требует совершенно 
иначе определить основной метод и метод с квалификатором :around, по 
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скольку объекты alphabet организованы принципиально иначе, чем буквы 
шифра. Метод с квалификатором :around, в частности, позволяет проверить 
является ли предположение о букве шифра или букве текста уже доказан¬ 
ным: 


(defmethod state-assumption :around (the-assumption (the-object alphabet)) 

(If (or (plain-letter-asserted-p the-object 

(the-plain-letter the-assumption)) 

(dpher-letter-asserted-p the-object 

(the-dpher-letter the-assumption))) 
nil 

(call-next-method))) 

Основной метод является более сложным и может быть выражен на 
псевдокоде так: 

;; установить эквивалент для буквы исходного текста 

;; установить эквивалент для буквы шифра 

;; образовать новую связь текст/шифр и внести ее в состав предположений о тексте 

;; образовать новую связь шифр/текст и внести ее в состав предположений о шифре 

На языке CLOS это можно выразить таким образом: 

(defmethod state-assumption (the-assumption (the-object alphabet)) 

(check-type the-assumption assumption) 

(let ((plain (the-plain-letter the-assumption)) 

(cipher (the-cipher-letter the-assumption)) 

(plain-map (the-plaintext-map the-object)) 

(cipher-map (the-dphertext-map the-object))) 

(if (pialn-letter-defined-p the-object plain) 

(push the-assumption (second (assoc plain plain-map))) 

(setf (the-plaintext-map the-object) 

(aeons plain (list (list the-assumption)) plain-map))) 



(setf (the-ciphertext-map the-object) 

(aeons cipher (list (list the-assumption)) cipher-map))) 
t)) 

В этом методе необходима проверка того, является ли та или другая 
буква уже определенной. В этом случае просто образуется новая связь букв. 
При отсутствии такой неопределенности необходимо инициализировать исход¬ 
ное значение связей текст/шифр и шифр/текст. Эти подробности не явля¬ 
ются существенными для обьектов-пользователей, поэтому алфавит (т.е. два 
списка связей букв) ограничен для доступа (доступ ведется через методы 
абстракций более высокого уровня). Выполним защиту указанного описания 
в следующей форме: 

(defmethod plain-letter-asserted-p ((the-object alphabet) the-letter) 

(check-type the-letter character) 

(let ((the-association (assoc the-letter (the-plaintext-map the-object)))) 

(and (not (null the-association)) 

(not (retractable-p (first (second the-association))))))) 
(defmethod cipher-letter-asserted-p ((the-object alphabet) the-letter) 

(check-type the-letter character) 

(let ((the-association (assoc the-letter (the-dphertext-map the-object)))) 

(and (not (null the-association)) 

(not (retractable-p (first (second the-association))))))) 
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Пробуем еще более обобщить эту операцию. Для источников знаний су¬ 
щественно знать, является ли некоторое множество букв частично или пол¬ 
ностью определенным. Предположим такую форму определения: 

(some-letter-p ’plain-letter-asserled-p 

(the-letters the-blackboard) 

’(#\A #\E #\I #\0 #\U)) 

Эта запись возвращает значение true (истина), если определена хотя бы 
одна из гласных букв. Можно оформить это же описание в виде макроопре¬ 
деления: 

(defmacro some-letter -р (text source letters) 

(list ’dolist (list ’Item letters ’nil) 

(list ’If (list text source ’item) 

(list ’return ’t)))) 

Модифицировав это макроопределение, можно определить операцию про¬ 
верки соответствия для целой группы букв: 

(defmacro all-letter-p (text source letters) 

(list ’dolist (list 'item letters ’t) 

(list 'if (list ’not (list text source ’item) 

(list ’return ’nil)))) 

Теперь мы готовы дать определение метода state-assumption для «класс¬ 
ной доски» в целом. Сначала изложим его на псевдокоде: 

;; внести предположение в список предположений 

;; определить это предположение для алфавита доски 

;; для всех букв «классной доски» 

;; установить данное предположение 


На языке CLOS этому соответствует запись: 

(defmethod state-assumption (the-assumption (the-blackboard blackboard)) 

(check-type the-assumption assumption) 

(push the-assumption (the-assumption the-blackboard)) 

(state-assumption the-assumption (the-alphabet theblackboard)) 

(dolist (item (the-letter the-blackboard) t) 

(if (equal (the-cipher-letter item) (the-cipher-letter the-assumption)) 

(state-assumption the-assumption item)))) 

В простейшем случае отмена предположения выражается в прерывании 
метода state-assumption. Например, чтобы отменить предположение о букве 
шифра, мы просто очищаем список предположений для исходного текста по 
данное (отвергнутое) предположение включительно. 

При этом ликвидируются и все предположения, построенные на оши¬ 
бочном допущении. Можно создать и более эффективный механизм. Допу¬ 
стим, что сделано предположение, согласно которому однобуквенное слово 
соответствует букве I (по некоторым причинам требуется гласная). Далее 
сделано предположение, что другому двухбуквенному слову соответствует 
NN (нужны согласные). Если первое предположение окажется ошибочным, 
то второе вполне может быть сохранено. При таком подходе класс 
assumption нужно дополнить еще одним слотом, в котором регистрируется 
связь предположений между собой (взаимная зависимость). 
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Подключение новых источников знаний 

Теперь, когда определены ключевые абстракции «классной доски* и ме¬ 
ханизмы выдвижения и проверки предположений, необходимо реализовать 
механизм вывода (класс inference-engiue) , связывающий все источники зна¬ 
ний в единое целое. Ранее уже упоминалось, что механизм вывода должен 
реализовать одну основную операцию, а именно обработку правил. Мы не 
будем на этом подробно останавливаться, поскольку этот метод не несет в 
себе принципиально новых решений. Убедившись в правильной работе меха¬ 
низма вывода, можно последовательно вводить в систему отдельные источни¬ 
ки знаний. Целесообразность последовательного процесса введения знаний 
объясняется двумя причинами: 

* Трудно заранее выяснить, какие правила существенны для каждого из ис¬ 
точников знаний, не испытав систему на конкретной задаче. 

* Отладка базы знаний существенно упрощается при включении в нее пра¬ 
вил порциями. 

Реализация источников знаний является предметом инженерии знаний и 
требует консультаций с «ксперта (это могут быть сами разработчики систе¬ 
мы или криптологи). При анализе источников знаний может выявиться, что 
одни правила бесполезны, другие слишком специализированы или излишне 
обобщены, а некоторых правил недостает. После такого анализа правила ис¬ 
точника знаний могут модифицироваться, а может потребоваться создание 
нового источника знаний. 

На рис. 11-7 показан механизм взаимодействия отдельных источников 
знаний с объектами «классной доски». Отметим, что^ каждый источник зна¬ 
ний управляет только списком относящихся к нему объектов (через слот 
the-references, наследованный от суперкласса dependent). 

Кроме того, каждый источник знаний связан с «классной доской» и мо¬ 
жет получать данные о состоянии всех объектов на доске. При активизации 
источника знаний с помощью контроллера (см. рис. 11-4) начинается дейст¬ 
вие соответсвующего механизма вывода по обработке связанных с ним объ¬ 
ектов. Это действие выражается в выдвижении и отмене предположений на 
основе механизма, который показан на рис. 11-6. 

В процессе реализации источников знаний могут выявиться общие для 
нескольких источников правила и (или) поведение. Например, источник зна¬ 
ний о структуре слов и источник знаний о структуре предложения могут 
иметь в своем составе общие правила относительно порядка отдельных букв 
и слов. В обоих случаях существо правил одно и то же, поэтому целесооб¬ 
разно ввести новый класс — источник знаний о структуре — и использо¬ 
вать его путем смешения для получения общего эффекта. 

Такое изменение структуры классов подчеркивает тот факт, что процесс 
обработки правил определяется не только источниками знаний, но и харак¬ 
тером объектов «классной доски». Например, один из источников знаний мо¬ 
жет реализовывать прямую цепь выводов в отношении одних объектов и об¬ 
ратную цепь в отношении других. Более того, различные источники знаний 
могут по-разному оперировать с одним и тем же объектом. Это дает повод 
перейти к более сжатому написанию методов на основе множественного по¬ 
лиморфизма, используемого в языке CLOS применительно к множественным 
методам. Возьмем для примера следующую обобщенную функцию: 

(defgeneric evaluate-rules 

(the-knowledge-source the-blackboard-object)) 



Common Lisp Object System. Система дешифрования 


397 



Можно сделать множественный метод специализированным по отноше¬ 
нию к виду источника знаний и к классу объектов доски: 

(defmethod evaluate-rules 

( (the-structure-knowledge-source structure-knowledge-source) 

(the-blackboard-object blackboard-object)) 

Этот метод специализирован в отношении класса structure-knowledge- 
source, но от вида объектов «классной доски» не зависит. Напротив, следую¬ 
щий метод: 

(defmethod evaluate-rules 

((the-small-word-source small-word-knowledge-source) 

(the-word word)) 


является зависимым как от класса small-word-knawledge-source, так и от 
word. 

11.4. МОДИФИКАЦИЯ 

Расширение функциональных возможностей 

В данном разделе мы попытаемся улучшить возможности проектируемой 
системы и определить ее чувствительность к вносимым изменениям. В ин¬ 
теллектуальных системах очень важно наряду с решением задачи получать 
информацию о ходе этого решения. Для этого нужно придать системе каче¬ 
ство самоанализа: регистрировать ход активизации источников знаний, при¬ 
чины и характер выдвигаемых предположений и т.д. (чтобы иметь возмож¬ 
ность запросить у системы, по какой причине сделано конкретное предполо¬ 
жение и к каким результатам оно приводит). 
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Для реализации такого свойства необходимо сделать две вещи. Во-пер¬ 
вых, нужно ввести механизм трассировки действий контроллера и источни¬ 
ков знаний, а во-вторых, модифицировать некоторые методы, чтобы они от¬ 
мечали соответствующую информацию. Общая схема механизма самоанализа 
(механизма объяснения) приведена на рис. 11-8. Суть механизма состоит в 
наличии некоторого общего регистратора всех действий источников знаний и 
контроллера. Посмотрим какие классы могут понадобиться для реализации 
механизма объяснения. 

Во-первых, для регистрации всех указанных выше действий введем 
класс action: 

(defclass action (> 

((who :accessor who rinitform :who) 

((what :accessor what :initform :what) 

((why :accessor why :initfonn :why) 

Экземпляр данного класса создается, например, при активизации конт¬ 
роллером какого-либо источника знаний. При этом в слот who (кто) зано¬ 
сится указание на контроллер, в слот what (что) — на источник знаний, а 
в слот why (почему) — какое-либо пояснение (например, приоритет сообще¬ 
ния или предположения). Для сбора и хранения объектов класса action ну¬ 
жен другой класс actions: 

(defclass actions О 

( (the-actions raccessor the-actions))) 

Этот класс должен входить в структуру класса cryptographer. Первая 
часть нашего нового механизма сделана, и вторая не будет сложной. По¬ 
смотрим на то, ще в нашей системе происходят основные события. Это мо¬ 
жет происходить в следующих пяти местах: 

* методы выдвижения предположений 

* методы отмены предположений 

* методы активизации источников знаний 

* методы обработки правил 

* методы регистрации решений, получаемых от источников знаний 
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Удобно использовать при этом методы с квалификаторами :before и 
:after. Возьмем для примера обобщенную функцию state-assumption, которая 
специализирована для букв шифра и алфавита. Для регистрации событий в 
этом методе воспользуемся квалификатором: after: 

(defmethod state-assumption :after (the-assumption (the-object assumable-object)) 

(let ((the-action (make-instance ’action 

:who the-object 
:what the-assumption 
:why <)))) 

(push the-action (the-actions ’cryptographer*)))) 

Нам не придется изменять код исходного основного метода, мы только 
уточняем поведение с помощью квалификаторов. Для полноты нам остается 
только создать объект, отвечающий на вопросы пользователя системы (кто? 
что? когда? почему?). Спроектировать такой объект не сложно, поскольку 
вся нужная для его работы информация может быть получена от объектов 
класса actions. 

Изменение технических требований 

Новые технические требования к системе могут быть удовлетворены при 
минимальных изменениях принятых проектных решений. Допустим, что 
предъявлено три вида новых требований к данной системе: 

* возможность дешифровки других языков (кроме английского) 

* возможность дешифровки шифра, использующего неоднозначные подста¬ 
новки букв 

* способность самообучения 

Первое требование самое простое, поскольку связь нашей системы с ан¬ 
глийским языком не является существенной. Эта связь отражается только на 
правилах источников знаний. Даже класс «алфавит» сделан независимым от 
конкретного набора букв. Второе требование существенно сложнее, но разре¬ 
шимо в рамках механизма «классной доски». Это потребует введения новых 
источников знаний относительно подстановки букв. Ключевые механизмы и 
абстракции при этом также сохранятся, но потребуется введение новых 
классов, которые будут действовать в рамках существующих механизмов. 
Самым трудным является последнее требование, так как обучение машин 
относится к области искусственного интеллекта. Можно, например, предло¬ 
жить контроллеру в тупиковых ситуациях обращаться за помощью к пользо¬ 
вателю системы. Такие подсказки могут регистрироваться системой и позво¬ 
ляют в дальнейшей работе избегать подобных тупиков. Такой простейший 
механизм обучения может быть введен в нашу систему без существенного 
изменения структуры классов и в пределах действующих механизмов. 

Дополнительная литература 

Englemore, Morgan [С, 1988] изложили исчерпывающие требования и подходы к системам 
на основе «классной доски», включая их создание, теорию, проектирование и примеры приме¬ 
нения. Есть два конкретных примера такой системы ВВ1 (проект Stanford и BLOB (министерст¬ 
во обороны Великобритании). Полезная информация по «классной доске» имеется у Hayes-Roth 
[J, 1985] и Nil [J, 1986]. Прямые и обратные цепочки вывода подробно рассмотрены для сис¬ 
тем основанных на базах правил у Barr и Feigenbaum [J, 1981]; Brachman и Levesque [J 1985]; 
Hayes-Roth. Waterman, Lena! [J, 1983]; Winston, Horn [G, 1989]. Meyer и Matyas [I, 1982] под¬ 
робно проанализировали разновидности шифров с точки зрения их дешифровки. Краткое описа¬ 
ние CLOS с примерами можно найти в приложении. 










Глава 12 


Ada. Система управления 
движением 

Индустрия создания программного обеспечения достигла к настоящему 
моменту такого уровня развития, что появилась возможность внедрить сред¬ 
ства автоматизации в множество новых областей, в диапазоне от микроком¬ 
пьютерного управления двигателем автомобиля до освобождения людей от 
значительной части рутинной работы при съемках кинофильмов и комплек¬ 
товании экипажей космических кораблей. Отличительной особенностью боль¬ 
ших систем является их чрезвычайно высокая сложность. Конечно, достойны 
уважения попытки упростить реализацию таких систем. Однако практика 
показывает, что сложности, возникающие при реализации больших систем, 
огромны. В крупных проектах нередко бывают задействованы сотни програм¬ 
мистов, которым необходимо написать миллион и более строк программ. 
При этом они должны учитывать множество требований, которые неизбежно 
меняются в процессе работы. Как правило, в рамках таких проектов созда¬ 
ется не одна программа, работающая на одном компьютере, а комплекс про¬ 
грамм, работающих в параллельной распределенной среде на большом числе 
связанных между собой компьютеров. Для того чтобы уменьшить вероят¬ 
ность неудачи при реализации большого проекта, обычно выбирают центра¬ 
лизованный принцип управления. Данная организация работ обеспечивает 
высокую надежность как при разработке архитектуры системы, так и при 
объединении ее частей. Некоторые части системы выполняются по субконт¬ 
рактам с другими компаниями. 

Группа разработчиков никогда не собирается вместе, так как, во- 
первых, люди работают в разных местах, и, во-вторых, происходит 
постоянная текучка кадров. 

Если за создание большой системы возьмется разработчик, который за¬ 
нимался написанием небольших программ, рассчитанных на одного пользова¬ 
теля, он столкнется с проблемой неопределенности и изменчивости принима¬ 
емых решений. Возможно, он решит, что глупо пытаться делать такую сис¬ 
тему. Но деловой и научный мир остро нуждается в больших системах. Во¬ 
образим себе использование ручной системы для управления авиационными 
полетами вокруг столичного центра, управление жизнеобеспечением членов 
космического корабля или отчетную деятельность международного банка. Ус¬ 
пешная автоматизация таких систем приводит не только к решению види¬ 
мых проблем, но также приносит множество осязаемых и неосязаемых вы¬ 
год, таких, как низкая операционная стоимость, высокая надежность, увели¬ 
чение функциональных возможностей. Конечно же, ключевое слово здесь — 
успешная. Ясно, что создание больших систем — чрезвычайно трудная зада¬ 
ча. Поэтому при ее решении необходимо применять все лучшее из инже¬ 
нерной практики и использовать интуицию ведущих проектировщиков. В 
этой главе представлена задача для демонстрации того, как объектно-ориен¬ 
тированное проектирование облегчает программирование больших проектов. В 
качестве языка программирования мы используем язык Ada, который явля¬ 
ется объектным, а не объектно-ориентированным, так как в нем не поддер¬ 
живается механизм наследования. 
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Требования к системе управления движением 

Система управления движением выполняет две главные функции: 
выбор маршрутов перевозок и контроль за транспортной системой. Эти 
функции включают планирование перевозок, контроль за перевозками, 
предотвращение конфликтов, прогнозирование неудач и регистрацию об¬ 
служивания. На рис. 12-1 приведена диаграмма основных элементов сис¬ 
темы управления движением. 

Система сбора и отображения информации на локомотиве состоит из 
множества дискретных и аналоговых датчиков для контроля таких пара¬ 
метров, как температура и давление масла, количество топлива, напряже¬ 
ние и сила тока на генераторе, число оборотов в минуту вала двигателя, 
температура воды, мощность тягового стержня. Значения с датчиков по¬ 
ступают к инженеру поезда через дисплейную систему, а к диспетчеру и 
обслуживающему персоналу, который находится вне поезда, через сеть 
передачи данных. Предупреждение или сигнал тревоги выбираются и ре¬ 
гистрируются всякий раз, когда показания любого датчика выходят за 
пределы нормального режима. Регистрация показаний датчиков использу¬ 
ется при проведении эксплуатационных работ и управлении расходом 
топлива. 

Система управления двигателем сообщает в реальном времени инже¬ 
неру поезда, как наиболее эффективно дросселировать и тормозить двига¬ 
тельные установки. Входными данными для этой системы являются: 
профиль и качество пути, ограничение по скорости, допустимые режимы, 
загрузка поезда и максимальная мощность. Исходя из этих данных, сис¬ 
тема может определить оптимальный по расходу топлива режим дроссели¬ 
рования и торможения двигательных установок, согласующийся с задан¬ 
ными режимами и требованиями безопасности. Рекомендации по дроссе¬ 
лированию и торможению двигательных установок, профиль и качество 
пути, местоположение и скорость поезда могут отображаться на бортовой 
дисплейной системе. 

Бортовая дисплейная система обеспечивает человеко-машинный ин¬ 
терфейс. На нее может выводиться информация с системы сбора и ото¬ 
бражения информации локомотива, системы управления двигателем и уст¬ 
ройства управления данными. Программируемые клавиши позволяют ин¬ 
женеру переключаться на различные дисплеи. 

Устройство управления данными предоставляет сервис шлюза между 
всеми бортовыми системами поезда и сетью передачи данных, к которой 
подключены все поезда, диспетчеры и прочие пользователи. Отслеживание 
маршрутов движения поездов осуществляется с помощью двух устройств, 
подключенных к сети передачи данных: транспондеров местоположения и 
глобальной спутниковой системы определения местоположения Навстар 
(GPS). Система сбора и отображения информации на локомотиве может 
определять положение локомотива с помощью счетчика, подсчитывающего 
число оборотов колеса. Эта информация извлекается из транспондеров 
местоположения, которые размещены через каждый километр пути и бо¬ 
лее часто на опасных участках. Транспондеры передают свою идентифи¬ 
кацию на устройство управления данными, из которой можно более точ¬ 
но определить местоположение поезда. Кроме того, поезд может быть 
подключен к приемникам GPS, с помощью которых положение поезда 
может быть определено с точностью до одного метра. 
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Околопутевые интерфейсные устройства размещаются там, где есть 
какое-либо управляемое устройство (например, переключатель), или дат¬ 
чик (например, инфракрасный датчик для обнаружения перегрева колес 
поезда). Каждое околопутевое интерфейсное устройство получает коман¬ 
ды от локального контроллера наземного терминала (например, такие, 
как включить и выключить сигнал). Устройства могут быть отключены с 
помощью местной системы управления. Кроме того, каждое устройство 
может сообщать свои установочные параметры. Наземный терминал 
транслирует информацию с околопутевых интерфейсных устройств на 
проходящий мимо поезд и обратно. Контроллеры наземных терминалов 
расположены вдоль железнодорожного пути через такие расстояния, что 
любой поезд всегда находится в зоне действия не менее одного из них. 

Каждый контроллер наземного терминала передает свою информацию 
на объединенную систему управления сетью. Связь между системой уп¬ 
равления сетью и контроллером наземного терминала может осуществ¬ 
ляться микроволновой связью, по наземным линиям или по оптоволокон¬ 
ной связи в зависимости от удаленности данного контроллера. Система 
управления сетью обеспечивает жизнеспособность всей сети. Она может 
автоматически направить информацию по другому пути в сети, если на 
прежнем пути произойдет отказ оборудования. 

Система управления в свою очередь подсоединяется к одному или 
нескольким диспетчерским центрам, которые составляют систему управле¬ 
ния железной дорогой, и к другим пользователям. В системе управления 
железной дорогой диспетчеры могут устанавливать маршруты поездов и 
колеи для движения отдельных поездов. Отдельный диспетчер управляет 
различными территориями; каждая диспетчерская управляющая консоль 
может быть подключена для управления одной или несколькими террито¬ 
риями. Маршрутизация поездов включает инструкции для автоматического 
перевода поезда с пути на путь, установку ограничения скорости, подачу 
и отправку автомобилей, разрешение и запрещение движения поезда в 
зависимости от занятости определенных участков пути. Диспетчеры могут 
отмечать состояние путей впереди по маршруту поезда для сообщения его 
инженеру поезда. Поезда могут быть остановлены системой управления 
железной дорогой (вручную или автоматически), когда обнаруживается 
опасность (такая, как выход поезда из графика, повреждение пути, воз¬ 
можность столкновения). Диспетчеры могут также вызвать любую инфор¬ 
мацию, доступную инженерам отдельных поездов, послать распоряжения 
по движению, установить параметры околопутевых устройств, пересмот¬ 
реть план. 

Расположение путей и околопутевое оборудование могут со временем 
изменяться. Число поездов и маршруты их движения могут изменяться 
ежедневно. Система должна обеспечивать возможность подключения но¬ 
вых датчиков, сетей передачи данных, оборудования, выполненного по 
более совершенным технологиям. 


Мы выбрали Ada, потому что из всех языков, используемых нами в 
этой книге, он наиболее пригоден для решения больших задач. Действитель¬ 
но, Ada был выбран для многих крупных проектов, таких, как Расширенная 
автоматическая система для FAA, Европейская космическая станция и систе¬ 
мы управления финансами Американской армии и крупнейшими банками в 
Финляндии. 



Рис. 12-1. Диаграмма основных элементов системы управления движения. 

12.1. АНАЛИЗ 

Определение границ задачи 

Для большинства людей, живущих в США, поезда являются продуктом 
давно ушедшей эпохи; в Европе ситуация совершенно противоположная. В 
отличие от США в Европе мало национальных и международных автомо¬ 
бильных магистралей, а цены на бензин и автомобили сравнительно высоки. 
Таким образом, поезда составляют основу транспортной сети континента; по 
десяткам тысяч железнодорожных путей перевозят ежедневно людей и грузы 
и в городах, и между странами. Ради справедливости отметим, что в США 
поезда играют по-прежнему важную роль в перевозке грузов. Добавим, что 
с увеличением городов их центры становятся все более и более перегружен¬ 
ными, и легкий рельсовый транспорт становится главным претендентом для 
решения проблем борьбы с перегрузками и загрязнения окружающей среды 
двигателями внутреннего сгорания. 

До сих пор железные дороги являются коммерческими и, следовательно, 
они должны быть прибыльными. Железнодорожные компании обязаны 
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постоянно поддерживать балланс между требованиями экономии и безопас¬ 
ности, с одной стороны, и нарастающей интенсивностью перевозок, с другой, 
что противоречит их эффективности и правилам составления расписаний. 
Эти противоречия наводят на мысль, что решения об управлении движением 
поездов необходимо получать автоматически, в том числе и контроль за 
всеми элементами железной дороги с помощью компьютера. Такие автомати¬ 
ческие и полуавтоматические системы сегодня существуют в Швеции, Вели¬ 
кобритании, Германии, Франции и Японии [12]. Подобная система, называ¬ 
емая Расширенной системой управления железнодорожным транспортом, су¬ 
ществует в Канаде и США. Ею пользуются следующие компании: Amtrak, 
Burlington, the Canadian National Railway Company, CP Rail, CSX 
Transportation, the Norfolk and Western Railway Company, the Southern 
Railway Company, Union Pacific [3]. Эффект от каждой из этих систем и 
экономический, и социальный; результатом их внедрения являются: низкая 
операционная стоимость, более эффективное использование ресурсов, а 
также увеличение безопасности (как побочный продукт). Выше 
сформулированы требования на высоком уровне к системе управления 
движением поездов. Очевидно, эти требования сильно упрощены. На практи¬ 
ке требования к системе настолько обширны, что к ним обращаются только 
после демонстрации жизнеспособности автоматически принимаемых решений; 
потом после многих сотен человеко-месяцев анализа в работу вовлекаются 
множество экспертов в данной области, и только после этого привлекаются 
пользователи и клиенты системы. В конечном итоге требования на большую 
систему могут состоять из тысяч страниц документации, специфицирующей 
не только базовое поведения системы, но и включающей такие подробные 
детали, как макеты экранов человеко-машинного интерфейса. 

Исходя из этих высокоуровневых требований, мы можем сделать два 
замечания о процессе разработки системы управления движением: 

* Процесс проектирования должен быть открыт для развития. 

* Реализация должна по возможности больше опираться на существующие 
практические стандарты. 

Наш опыт разработки больших систем подсказывает, что первоначаль¬ 
ная формулировка требований никогда не бывает полной, она всегда в неко¬ 
торой степени неопределенна и противоречива. Мы не должны забывать, что 
процессу проектирования свойственна некоторая неопределенность, и, следо¬ 
вательно, мы должны быть готовы к корректировкам проекта. Эти корректи¬ 
ровки могут быть или просто добавлением новых деталей, или постепенным 
интерактивным процессом. Мы уже говорили в гл. 4, что такое противоре¬ 
чие дает и пользователям, и разработчикам лучшее понимание предмета 
проектирования, чем попытка написать требования на систему без предвари¬ 
тельного прототипирования. Кроме того, необходимо учитывать, что на со¬ 
здание большой системы может быть затрачено несколько лет. За это время 
уйдет вперед технология аппаратной части системы. Это повлечет за собой 
изменения в аппаратнозависимых модулях программной части. Мы считаем, 
что для уменьшения количества изменений проектировщики должны макси¬ 
мально использовать существующие стандарты на связь, сети передачи дан¬ 
ных, машинную графику и датчики. Разработка же новых нестандартных 
аппаратных и программных средств приведет к повышению вероятности неу¬ 
дачи, которая для большинства систем и без того высока. Нашей же целью 
является снизить эту вероятность до минимума. Мы не затрагиваем вопросы 
анализа больших систем, так как книга в основном посвящена проектиро- 
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ванию. Да и вряд ли можно рассмотреть все вопросы анализа в одной кни¬ 
ге. Но мы хотим отметить, что объектно-ориентированный анализ — это 
идеальный метод анализа для систем, подобных нашей. И прежде всего по¬ 
тому, что он позволяет разговаривать разработчикам и пользователям на од¬ 
ном языке на основе общего словаря проблемной области. В результате объ¬ 
ектно-ориентированного анализа должны быть определены ключевые абстрак¬ 
ции и предполагаемое поведение системы. 

В отличие от предыдущих глав размеры данной задачи не позволяют 
привести здесь детальный проект и тем более полную реализацию системы. 
Поэтому мы покажем лишь процесс проектирования наиболее высокого уров¬ 
ня системы, записанный с помощью объектно-ориентированной нотации. 

Требования к системе и к программному обеспечению 

Крупные проекты обычно вырастают из более мелких, которые создава¬ 
лись единым коллективом. Как правило, архитектура системы тоже создает¬ 
ся этим коллективом, а потом части системы реализуются различными орга¬ 
низациями или различными коллективами внутри одной организации. На 
стадии анализа системы происходит создание модели состояний из аппарат¬ 
ной и программной частей. Многие считают, что это уже не анализ, а про¬ 
ектирование. Это спорный вопрос. В самом деле, трудно понять, что показа¬ 
но на диаграмме на рис. 12-1, требования или проект системы. Несмотря на 
это, хорошо видно, что на этой стадии разработки архитектура системы яв¬ 
ляется принципиально объектно-ориентированной. Например: в ней присутст¬ 
вуют такие сложные объекты, как системы управления двигателем и система 
управления железной дорогой. Обе они выполняют основные функции систе¬ 
мы. Это как раз то, о чем мы говорили в гл. 4 — объекты самого 
высокого уровня абстракции группируются по функциональным признакам. 
Поэтому процесс анализа в данном случае мало отличается от процесса 
проектирования. 

Когда мы имеем архитектуру на уровне блок-диаграмм (рис. 12-1), мы 
должны разработать системные требования на уровне каждого блока, как 
это сделано выше (разд. «Требования к системе управления движением»). 
Для большей детализации мы можем использовать диаграммы потоков дан¬ 
ных, объектов или структурированный текст, чтобы проиллюстрировать взаи¬ 
модействие различных частей системы, в том числе влияние уровня 
детализации на поведение системы в целом. 

Очевидно, мы должны преобразовать требования к системе в требования 
к программной и аппаратной частям системы, так чтобы различные органи¬ 
зации могли одновременно заниматься отдельными частями задачи. Совмест¬ 
ное создание аппаратного и программного обеспечения — сложная задача, 
особенно если эти части связаны достаточно слабо и создаются разными 
фирмами. Иногда интуитивно ясно, какая аппаратура будет использоваться. 
Например, можно использовать готовые терминалы или рабочие станции на 
бортовых дисплейных системах и для отображения информации в центрах 
управления железной дорогой. Очевидно также, что программы могут хоро¬ 
шо составлять расписания поездов. Окончательное решение о том, какую ос¬ 
нову — аппаратную или программную — использовать в каждом конкрет¬ 
ном случае, зависит как от привычек разработчиков, так и от многих дру¬ 
гих факторов. Специализированную аппаратуру можно использовать, когда 
важнее производительность, а программы, когда более важна гибкость. 
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Рис. 12-2. Диаграмма процессов для системы управления движением. 

При решении нашей задачи мы считаем, что первоначальный вариант 
аппаратной архитектуры следует из архитектуры системы. Это предположе¬ 
ние не является окончательным, оно дает нам отправную точку для уточне¬ 
ния требований к программному обеспечению. Действительно, чтобы продол¬ 
жить проектирование, нам необходима свобода выбора аппаратных и про¬ 
граммных средств обеспечения: позже станет ясно, какая дополнительная ап¬ 
паратура нам необходима, или что предпочтительнее для выполнения опре¬ 
деленных функций: программы или аппаратура. 

На рис. 12-2 показано целевое аппаратное обеспечение для системы уп¬ 
равления движением; здесь используются наши обозначения для диаграмм 
процессов. Эта архитектура процессов соответствует блок-диаграмме системы 
на рис. 12-1. В частности, существуют один бортовой компьютер на каждом 
поезде, охватывающая локомотив система сбора и отображения информации 
на локомотиве, система управления двигателем, бортовая дисплейная система 
и устройство управления данными. Мы предполагаем, что некоторые борто¬ 
вые устройства, такие, как дисплей, обладают интеллектом, и считаем, что 
они не нуждаются в программировании. Мы полагаем, что каждый локаль- 
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ный транспондер подсоединен к передатчику, который может посылать сооб¬ 
щения на проходящий мимо него поезд; компьютер к локальному транспон¬ 
деру не подсоединен. Все группы околопутевых устройств (каждое из кото¬ 
рых входит в устройство околопутевого интерфейса) управляются компьюте¬ 
ром, который может взаимодействовать с проходящим поездом или с конт¬ 
роллером наземного терминала через их передатчики и приемники. Каждый 
контроллер наземного терминала присоединяется через сеть передачи данных 
к диспетчерскому центру (который входит в систему управления железной 
дорогой). Для обеспечения бесперебойного обслуживания мы решили разме¬ 
стить на каждом диспетчерском центре два компьютера: основной и резерв¬ 
ный (который подключится в случае отказа основного компьютера). В пери¬ 
од простоя резервный компьютер может использоваться для обслуживания 
других, низкоприоритетных пользователей. 

Сданная в эксплуатацию система управления движением может 
содержать сотни компьютеров: по одному на каждый поезд, по одному на 
каждое околопутевое интерфейсное устройство, и по два на каждый диспет¬ 
черский центр. На диаграмме процесса показано только несколько из этих 
компьютеров, так как излишне показывать повторяющуюся конфигурацию. 

Как мы уже говорили в гл. 7, здравый смысл подсказывает, что при 
разработке большого проекта огромную роль играют разумность и ясность 
интерфейсов между ключевыми частями системы. Особенно это важно для 
интерфейса между программной и аппаратной частями системы. В начале 
работы над проектом интерфейс может быть определен не полностью, но он 
должен быть достаточно быстро формализован, чтобы различные части сис¬ 
темы можно было разрабатывать, тестировать и выпускать одновременно. 
Хорошо определенный интерфейс позволяет производить сборку системы без 
существенных переделок ее частей. Кроме того, мы не рассчитываем, что 
все разработчики, участвующие в проекте, будут одинаково сильны в про¬ 
граммировании. Спецификации ключевых абстракций и механизмов позволят 
всем воспользоваться результатами работы сильнейших системных архитек¬ 
торов. 

Ключевые абстракции и механизмы 

В результате изучения требований к системе управления движением 
становится видно, что реально мы должны решить четыре подзадачи: 

* Сеть передачи данных. 

* База данных. 

* Человеко-машинный интерфейс. 

* Аналоговые устройства управления в реальном времени. 

Эти четыре проекта представляют наибольший риск при разработке 
проекта нашей системы. 

Действительно, нить, которая связывает всю систему воедино, — это 
распределенная сеть передачи данных. Сообщения с помощью радио переда¬ 
ются с транспондеров на поезд, между контроллерами наземных терминалов, 
между поездами и околопутевыми интерфейсными устройствами, между кон¬ 
троллерами наземных терминалов и околопутевыми интерфейсными устройст¬ 
вами. Кроме того, сообщение должно передаваться между диспетчерскими 
центрами и отдельными контроллерами наземных терминалов. Надежная ра¬ 
бота всей системы обеспечивается своевременными и надежными приемом и 
передачей сообщений. Кроме того, эта система должна одновременно хра¬ 
нить местоположения и маршруты множества поездов. Мы должны хранить 
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постоянно обновляемую информацию даже в случае попыток одновременно 
записать и считать информацию из сети передачи данных. Это фундамен¬ 
тальная проблема распределенных баз данных. 

Проектирование человеко-машинного интерфейса требует решения особо¬ 
го множества задач. Дело в том, что пользователями системы в основном 
являются инженеры поездов и диспетчеры и лишь немногие из них умеют 
квалифицированно использовать компьютер. Пользовательский интерфейс 
операционных систем, таких как Unix, пригоден для специалиста-программ- 
иста, но слишком неудобен для пользователей готового программного про¬ 
дукта, такого, как система управления движением. Следовательно, все фор¬ 
мы взаимодействия должны быть спроектированы в расчете на эту особую 
группу пользователей. Наконец, система управления движением должна вза¬ 
имодействовать с разнообразными датчиками и исполнительными механизма¬ 
ми. Останавливаясь здесь на природе этих устройств, отметим, что контроль 
и управление ими сходны и будут осуществляться одним и тем же спосо¬ 
бом. 

Каждую из этих четырех задач можно решать по отдельности. Систем¬ 
ные архитекторы должны разработать ключевые абстракции и механизмы, 
общие для каждой задачи, и тогда мы можем выбрать экспертов для реше¬ 
ния каждой отдельной подзадачи одновременно с остальными. Из краткого 
проблемного анализа этих четырех задач мы находим, что существуют три 
высокоуровневые ключевые абстракции: 

* Поезда Поезда и автомобили. 

* Пути Профиль пути впереди поезда, качество и около¬ 

путевые устройства. 

* Планы Составление, упорядочивание' устранение накладок, 

назначение полномочий и выработка команд. 

Каждый поезд характеризуется текущим положением и может иметь 
только один активный план движения, который описывает прохождение по¬ 
езда по его маршруту. Мы можем выделить ключевой механизм для каждой 
из четырех подзадач: 

* Механизм передачи сообщений. 

* Механизм планирования движения поездов. 

* Механизм отображения информации. 

* Механизм датчиков. 

Почему мы выделяем эти механизмы еще до начала процесса проекти¬ 
рования? Дело в том, что эти четыре механизма — основа нашего проекта. 
Они являются наиболее сложными и рискованными частями системы. Важно, 
чтобы мы выбрали лучшее решение из всех возможных. Ведь именно эти 
проектные решения определят дальнейшую работу всего коллектива. 

12.2. ПРОЕКТИРОВАНИЕ 
Механизм передачи сообщений 

При анализе механизма передачи сообщений мы обращаемся к концеп¬ 
ции словаря предметной области, как к наиболее высокоуровневой абстрак¬ 
ции. Например, типичное сообщение в системе управления движением состо¬ 
ит из сигнала запуска околопутевых устройств, признаков прохождения по- 
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езда через определенный участок пути и приказов диспетчера для инженера 
поезда. Все эти виды сообщений могут передаваться внутри системы управ¬ 
ления движением на двух уровнях: 

* Между компьютерами и устройствами. 

* Между компьютерами. 

Сейчас нас интересует второй уровень передачи сообщений. Так как 
наша система включает территориально распределенную сеть передачи дан¬ 
ных, мы должны учесть такие факторы, как помехи, отказы оборудования и 
секретность передачи информации. 

Анализ требований к связи. Первым шагом при определении сообщений 
в системе может быть анализ взаимодействия каждой пары связанных меж¬ 
ду собой компьютеров (рис. 12-2). Для каждой пары компьютеров мы долж¬ 
ны ответить на два вопроса: какая информация будет передаваться с компь¬ 
ютера на компьютер? Какой уровень абстракции будет иметь эта информа¬ 
ция? Мы должны при этом использовать последовательный итеративный под¬ 
ход, пока не будем уверены, что передаются правильные сообщения и в си¬ 
стеме связи нет «узких» мест («узкие» места могут возникать из-за пере¬ 
грузки линий связи либо в том случае, если длина сообщений или слишком 
мала, или слишком велика). 

Очень важно, чтобы на данном этапе проектирования внимание было 
сосредоточено на сути, а не на форме сообщений. Часто системные архитек¬ 
торы начинают проектирование с выбора битового представления сообщений. 
Когда в реальной задаче делается преждевременный выбор, такой, как низ¬ 
коуровневое представление, это обязательно приведет к изменениям в даль¬ 
нейшем и, таким образом, затронет всех, кто пользовался этим представле¬ 
нием. Кроме того, на этой стадии проектирования у нас пока нет полной 
информации, как будут использоваться данные сообщения, и, следовательно, 
мы не можем судить, какое представление будет оптимальным по размеру и 
времени передачи. 

Концентрируя внимание на сути сообщений, мы рассмотрим все классы 
сообщений. Другими словами, мы должны определить назначение и смысл 
каждого сообщения, а так же операции для их содержательной обработки. 

На диаграмме классов (рис. 12-3) показаны некоторые наиболее важные 
сообщения в системе управления движением. Заметим, что все сообщения в 
конечном итоге являются экземплярами класса Message, который обобщает 
поведение для всех классов. Три абстрактных класса представляют главные 
категории сообщений: сообщение о состоянии поезда, сообщение о плане 
движения поезда, сообщение околопутевого устройства. Каждый из этих трех 
классов в дальнейшем будет специализирован. В результате проектирования 
должны появиться сотни таких специализированных классов. Таким образом, 
существование обобщающих абстрактных классов черезвычайно важно; без 
них мы получили бы сотни несвязанных и, следовательно, сложных при ис¬ 
пользовании модулей, каждый из которых реализирует специализированный 
класс. По мере проектирования мы будем создавать другие важные группы 
сообщений и затем придумывать для них другие специализированные проме¬ 
жуточные абстрактные классы. 

Реализация проекта. Как мы реализируем этот проект на языке Ada, 
который является объектным языком программирования и, таким образом, 
не имеет прямой поддержки механизма наследования? На практике мы про¬ 
водим проектирование так, как будто наследование возможно, а затем, если 
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• Сообщение >' 



Рис. 12-3. Диаграмма классов сообщений. 

язык не имеет прямой поддержки механизма наследования, эмулируем его. 
В Ada общий подход заключается в использовании комбинации параметризо¬ 
ванных пакетов (представляющих параметризованные классы) и различных 
собственных типов (представляющих абстрактные классы). Из рис. 12-3 вид¬ 
но, что класс Message является параметризованным классом, который реали¬ 
зуется в Ada как тип, экспортируемый из параметризованного пакета, и со¬ 
держит операции, общие для всех сообщений, такие, как передача и прием. 
Затем абстрактные классы, подобные Train_Status_Message, могут быть пред¬ 
ставлены как собственные типы. Например, мы можем написать класс 
Train_Status_Message следующим образом: 

with SystemClasses; 

package Train Status Messages is 

type Kind is (Train_Location, Train_Speed, Train_Stop); 
type Train_Status_Message (TheJCind : Kind) is private; 

procedure Set_Location (The_Message : in out Train_Status_Message; 

The_Location : in System_Classes.Location); 

procedure Set_Speed (The_Message : in out Train_Status_Message; 

The_Speed : in System Classes.Speed); 

procedure Stop (The_Message : in out Train_Status_Message); 
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function Location_Of (The_Message : in Train_Status_Message) 

return System_Classes.Location; 

function Speed_Of (The_Message : in Train_Status_Message) 

return System_Classes.Speed; 

function Is_Stopped (The_Message : in Train_Status_Messge) return Boolean; 

end Train_Status_Messages; 

Пакет System_Classes содержит общие определения для таких классов, 
как Location и Speed. 

Как показано на диаграмме классов (рис 12-3), каждый экземпляр 
класса Message добавляет новый тип. Так как эти экземпляры структурно 
связаны между собой, то подклассы промежуточных классов (подобных 
Train_Status_Message) добавляют совместимые друг с другом типы. 

Когда наш интерфейс будет содержать все наиболее важные сообщения, 
мы можем начать писать программы, основанные на этих классах для моде¬ 
лирования протоколов передачи сообщений. Эти программы можно использо¬ 
вать для тестирования различных частей системы. 

Диаграмма классов на рис. 12-3, конечно, неполна. Ясно, что в первую 
очередь необходимо разрабатывать наиболее важные сообщения, а все ос¬ 
тальные добавлять по мере того, как будем обнаруживать менее общие фор¬ 
мы взаимодействия. Использование объектно-ориентированного проектирова¬ 
ния позволит добавлять эти сообщения без нарушения существующих частей 
системы, так как эти изменения задуманы нами с самого начала. 

Если мы удовлетворены структурой классов, мы можем начать проекти¬ 
рование самого механизма передачи сообщений. Здесь возникают две проти¬ 
воречащие друг другу цели: придумать механизм для надежной доставки со¬ 
общений и сделать это на достаточно высоком уровне абстракции, так что¬ 
бы клиенту не надо было заботиться о доставке сообщения. Такой механизм 
передачи сообщений позволит клиентам иметь упрощенное представление о 
процессе передачи. 

На рис. 12-4 показан результат проектирования механизма передачи со¬ 
общений. Для посылки сообщения применяют операцию Send (определенную 
в подклассе Message) к объекту сообщения. Эта операция по очереди вызы¬ 
вает асинхронную операцию Send, применяемую к некоторому сосредоточен¬ 
ному объекту Message_Manager. Мы сделали эту операцию асинхронной, 
чтобы клиент не ждал, пока сообщение будет отправлено по радио, что тре- 
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бует времени для кодирования, декодирования и повторных передач из-за 
помех. В конечном итоге объект Message_Manager преобразует значение 
каждого специализированного объекта сообщения в некоторую каноническую 
форму, вероятно содержащую поток букв и цифр, а затем направляет этот 
поток в соответствующее место через сеть передачи данных. 

При проектировании объекта Message_Manager мы помещаем его на 
прикладной уровень OSI модели, принятой в ISO [4]. Это позволит всем 
клиентам-передатчикам и клиентам-приемникам работать на самом высоком 
уровне абстракции и общаться друг с другом в собственных терминах. На¬ 
значение объекта Message_Manager состоит в том, чтобы скрыть все низко¬ 
уровневые детали физической передачи этих сообщений. 

Рассмотрим внутреннее представление объекта Message_Manager. Этот 
объект должен находиться на каждом компьютере, который отправляет или 
получает сообщения. Его основная семантика гарантирует передачу и прием 
всех видов сообщений. Так как передача может быть прервана из-за воз¬ 
никновения ошибок (таких, как ошибки при радиопередаче), то эти объекты 
должны реагировать на подобные исключительные ситуации. 

Параметризованные пакеты Ada хорошо приспособлены для реализации 
таких объектов. Сначала мы параметризуем пакет дискретным типом, пред¬ 
ставляющим все возможные типы сообщений. Этот параметризованный пакет 
скрывает устройство двух внутренних параметризованных процедур: одну для 
посылки и другую для приема сообщений. Реализация классов сообщений 
может содержать экземпляр каждой или обеих процедур. Эти процедуры 
включают операцию по преобразованию каждого типа сообщений в канони¬ 
ческую форму. Таким образом, каждый класс сообщений скрывает детали 
низкоуровневого представления этого сообщения. Все классы сообщений мо¬ 
гут быть построены на основе набора стандартных функций для преобразо¬ 
вания сообщений. 

Мы можем описать пакет Message_Manager следующим образом: 


with Network_Classes; 

type Message_Kind is (< >); 
package Message_Manager is 


type Message is private; 
with function String_To_Message (The_String 
return Message; 
re Send (The_Message 


To 


in Network_Classes.Id; 
in Network_Classes.Id; 
in Network_Classes.Retry_Count; 
in Boolean); 


type Message is private; 

with function Message_To_String (The_Message : 
procedure Receive (The_Message : c 

From 

To : in 

function Kind_Of_Message return Message_Kind; 

Transmision_Error : exception; 

Reception_Error : exception; 
d Message_Manager; 
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Пакет Network_Classes содержит базовые определения, такие, например, 
как ID — тип для уникальной идентификации узлов в сети передачи дан¬ 
ных. Обратите внимание на описание двух исключений: Transmission_Error 
и Reception_Error, которые могут быть вызваны тогда, когда сообщение не 
может быть нормально передано или принято. 

Мы считаем, что окончательная реализация этого параметризованного 
пакета будет немного сложнее. Например, мы могли бы добавить к опера¬ 
циям передачи и приема опции для синхронизаций связи или для тайма-у- 
тов. Мы также можем добавить больше исключений, чтобы точнее иденти¬ 
фицировать причины ошибок передачи и приема. В любом случае спроекти¬ 
рованная таким образом модель позволяет всем клиентам работать на самом 
высоком уровне абстракции, взаимодействуя друг с другом в терминах их 
специфической области приложения. С другой стороны, эти модули скрыва¬ 
ют множество сложных вещей. Отметим, для того чтобы иметь дело с фи¬ 
зической передачей сообщений, эти модули должны быть построены на осно¬ 
ве общей низкоуровневой абстракции. Это позволяет выполнять шифрование 
и дешифрование и использовать коды для обнаружения и исправления оши¬ 
бок, что в свою очередь обеспечивает надежную связь в случае ошибок пе¬ 
редачи или отказов оборудования. 

Механизм планирования движения поездов 

Выше мы говорили, что концепция планирования движения поездов яв¬ 
ляется центральной для функционирования системы управления движением. 
Каждый поезд имеет один активный план, а каждый план назначается 
только одному поезду. Он может содержать много различных приказов и то¬ 
чек на пути. Наш первый шаг состоит в определении, из каких частей со¬ 
стоит план поезда. Для этого мы должны определить всех потенциальных 
клиентов плана и их способ использования этого плана. Например, некото¬ 
рым клиентам может быть разрешено составлять планы, другим может быть 
разрешено корректировать планы, а остальные смогут только читать планы. 
В этом смысле план действует как хранилище информации, связанной с 
маршрутом одного отдельного поезда и действиями, которые надо произвести 
во время движения. Примером таких действий может быть подача или от¬ 
правка автомобилей. 
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Время 

Место 

Скорость 

Автор 

Порядок 

0800 

Pueblo 

Как почтой 


Покинуть сорти¬ 
ровочную станцию 

0815 

Pueblo 

Как почтой 

See 

Yardmaster 

Подать 50 машин 

1100 

Colorado 

Springs 

40 МРН 


Отправить 30 машин 

1300 

Denver 

45 МРН 


Отправить 20 машин 

1600 

Pueblo 

Как почтой 


Вернуться на сорти¬ 
ровочную станцию 


На рис. 12-5 приведены проектные решения, касающиеся структуры 
класса Тгаіп_Р1ап. Как и в гл. 10, мы используем диаграмму классов, что¬ 
бы показать части, из которых состоит план движения поезда (подобно то¬ 
му, как это делается на традиционных диаграммах отношений объектов). 
Мы видим, что каждый план содержит один поезд и может содержать много 
приказов и действий. Мы ожидаем, что эти действия будут упорядочены во 
времени и с каждым действием связана такая информация, как время, мес¬ 
тоположение, скорость, полномочия, приказы. Например, план может содер¬ 
жать следующие действия: 

Так же как для класса Message и его подклассов, мы можем в первую 
очередь спроектировать наиболее важные элементы плана поезда; его детали 
будут создаваться по мере того, как мы будем применять план к новым 
задачам. 

Тот факт, что мы можем иметь множество активных и неактивных 
планов поездов одновременно, ставит вопрос о создании базы данных, о ко¬ 
торой мы уже говорили. Диаграмма классов на рис. 12-5 может служить 
наброском логической схемы этой базы данных. Следующий вопрос, который 
возникает при этом состоит в следующем: где находится план поезда? 

В идеальном случае без помех или задержек при передаче и неограни¬ 
ченных ресурсах компьютера лучше всего было бы разместить все планы 
поезда в единой централизованной базе данных. Такой подход обеспечивает 
существование единственного экземпляра каждого плана поезда. Однако ре¬ 
альные условия делают это решение не эффективным. Мы предполагаем, 
что будут задержки при передаче и производительность процессора ограни¬ 
чена. Таким образом, скорость доступа к плану, который расположен в дис¬ 
петчерском центре, с поезда не будет отвечать всем требованиям реального 
времени. Однако мы можем создать иллюзию наличия централизованной ба¬ 
зы данных с помощью нашего программного обеспечения. Наше решение за¬ 
ключается в том, что планы поездов будут располагаться на компьютерах 
диспетчерского центра, а копии индивидуальных планов — распределяться 
при необходимости по сети передачи данных. Для обеспечения необходимой 
эффективности компьютер каждого поезда может хранить копию активного 
плана. Таким образом, бортовое программное обеспечение может сделать за¬ 
прос по этому плану с минимальной задержкой. Если план изменяется в 
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Рис. 12-6. Механизм планирования движения поезда. 

результате действий диспетчера или (что менее вероятно) по решению ин¬ 
женера поезда, наши программы должны гарантировать, что все копии этого 
плана обновятся одинаково. 

На рис. 12-6 показано, как происходит передача и обновление копий 
плана. Первоначально единственная копия плана движения находится в цен¬ 
трализованной базе данных на диспетчерском центре. Затем по сети может 
быть разослано любое число копий этого плана. Когда копия плана посыла¬ 
ется клиенту, в базе данных записывается ее местоположение. Теперь пред¬ 
положим, что в результате действий инженера поезда появилась необходи¬ 
мость изменить план движения этого поезда. Сначала изменяется копия 
плана, находящаяся на поезде. Затем сообщение об изменениях посылается 
в централизованную базу данных на диспетчерский центр. После того как 
план изменился в базе данных, сообщения об изменениях рассылаются всем 
остальным клиентам, которые имеют у себя копии данного плана. 

Этот механизм работает и тогда, когда изменения в план движения 
вносит диспетчер, в этом случае сначала изменяется копия плана в базе 
данных, а затем сообщения об изменениях рассылаются по сети остальным 
клиентам. Как в обоих случаях осуществляется передача изменений? Для 
этого мы используем механизм передачи сообщений, разработанный нами 
ранее. Заметим, что в результате проектирования мы добавили новое сооб¬ 
щение о плане движения поезда. Работа с этим сообщением базируется на 
уже существующем низкоуровневом механизме передачи сообщений. 

Использование существующей коммерческой системы управления базами 
данных позволит обеспечить резервирование, отходы назад, ведение конт¬ 
рольного журнала и секретность информаций. 

Механизм отображения информации 

Использование готовых технологических решений для механизма отобра¬ 
жения информации, так же как для базы данных, позволит нам сосредото- 
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читься на отдельных частях нашей задачи. Этого можно добиться, если ис¬ 
пользовать графические стандарты, такие, как GKS, PHIGS или XWindows. 
Использование готовых графических программных средств поднимает уровень 
абстракции нашей системы настолько, что разработчикам не надо беспоко¬ 
иться об обработке отображенной информации на уровне пикселов. 

Рассмотрим, например, отображение информации о профиле и качестве 
участков пути. Согласно требованиям отображение может появиться в двух 
местах: на диспетчерском центре и на поезде (где отображается путь только 
впереди по маршруту движения поезда). Считая, что мы имеем некоторый 
класс, экземпляры которого представляют участки пути, можно рассмотреть 
два подхода к визуализации этого объекта. В соответствии с первым 
подходом, создается специальный объект, управляющий отображением, кото¬ 
рый преобразует состояние объекта в визуальную форму. По второму мы 
отказываемся от этого специального внешнего объекта, но вместо этого в 
каждом нашем объекте помещаем информацию, как отображать самого себя. 
Мы считаем, что второй подход предпочтительней, так как он проще и луч¬ 
ше отражает сущность объектной модели, хотя и не лишен недостатков. 

В конце концов у нас будет множество разновидностей отображенных 
объектов, каждый из которых создан разными группами разработчиков. Если 
реализовывать каждый отображаемый объект отдельно, то получим избыточ¬ 
ный код, разный стиль и большую путаницу. Правильнее проанализировать 
все разновидности отображаемых объектов, определить, какие из них общие 
элементы, и создать множество промежуточных классов, которые обеспечат 
отображение этих общих элементов. В свою очередь эти промежуточные 
классы могут быть построены на основе существующих низкоуровневых гра¬ 
фических пакетов. 

На рис. 12-7 показана реализация всех отображаемых объектов, разде¬ 
ляющих общие промежуточные классы. Эти классы построены на основе 
низкоуровневых услуг пакета XWindows, которые скрыты от всех производ¬ 
ных классов. Основное достоинство этого подхода заключается в том, что 
уменьшается влияние любых измерений аппаратуры или программ на низ¬ 
ком уровне. Например, если нам надо заменить наши дисплеи на более или 
менее мощные устройства, придется изменять программы только в 
Train_Display_Utilities. 



Рис. 12-7. Механизм отображения информации. 
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Без такой декомпозиции программ нам бы пришлось вносить изменения 
в каждый отображаемый объект при любых изменениях на нижнем уровне. 

Механизм датчиков 

Выше мы говорили, что система управления движением должна вклю¬ 
чать в себя большое количество разнообразных датчиков. Например, на 
каждом поезде датчики следят за температурой масла, количеством топлива, 
дроссельной установкой, температурой воды, нагрузкой на тяговый стержень 
и т.д. Активные датчики околопутевых устройств сообщают текущее положе¬ 
ние своих переключателей. Все виды возвращаемых датчиками величин раз¬ 
ные, но обработка этих величин производится похоже. Например, допустим, 
что наш компьютер использует привязанный к фиксированным адресам па¬ 
мяти ввод-вывод, тогда данные каждого датчика одинаково читаются из оп¬ 
ределенной области памяти и только потом интерпретируются зависящим от 
конкретного датчика способом. Так же большинство датчиков должно пере- 
одически проверяться. Для всех датчиков справедливо, что, если величины 
находятся в пределах заданных границ, клиенту не сообщается ничего, кро¬ 
ме поступления новой величины. Если же величина вышла из заданных 
границ, об этом могут быть оповещены разные клиенты. Если такая величи¬ 
на выйдет далеко за границы, мы можем дать какой-то сигнал тревоги и 
побудить других клиентов предпринять решительные действия (например, 
когда давление масла на локомотиве поднимается до опасного уровня). 

Повторение описанных выше действий не только приводит к 
монотонности и появлению ошибок, но и к созданию избыточного кода. Ес¬ 
ли мы с самого начала не выделим общие для всех датчиков части, то все 
разработчики предложат свои решения одной и той же задачи. Это в свою 
очередь приведет к сложностям при сопровождении системы. Поэтому для 
выявления общих свойств необходимо провести анализ всех дискретных не¬ 
циклических датчиков. 

Рассмотрим внешнее представление этого базового класса и ответим на 
вопрос: какие действия мы можем совершать над их экземплярами? Здесь 
возможны три варианта: два модификатора и один селектор. Во-первых, мы 
должны показать, как провести начальную установку параметров датчика. 
Затем, мы должны сказать, как часто обновляются величины датчиков, и 
определить границы его допустимых и недопустимых значений. Для полноты 
мы должны также предусмотреть операцию, производящую остановку датчи¬ 
ка. И наконец, мы можем добавить селектор для принудительного чтения 
текущего значения датчика. 

Возможны ли во время работы датчика аномальные ситуации? Клиент 
может пытаться запустить уже работающий датчик (мы не рассматриваем 
попытку остановить неработающий датчик как ошибку). Кроме того, может 
произойти непоправимая ошибка, которая связанна с аппаратурой и которую 
мы можем обнаружить при попытке прочесть его значение. Средствами об¬ 
работки особых ситуаций в языке Ada легко сделать так, чтобы эти ошибки 
не влияли на пользователей. 

Операции, которые мы можем выполнить над объектом, это — только 
половина устройства объекта; мы также должны учитывать, что операции 
этого объекта используют другие объекты. Для этого базового класса датчи¬ 
ков мы можем рассмотреть четыре операции: три модификатора и один се¬ 
лектор. Три модификатора соответственно обеспечивают получение значения 
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датчика, предупреждение клиента о ненормальном значении и подачу сигна¬ 
ла тревоги клиенту, если значение достигает опасной величины. Нам необ¬ 
ходим селектор, который сообщает датчику, как преобразовать входной по¬ 
ток битов в величину, соответствующую данному датчику. Эти данные луч¬ 
ше связывать с классами датчиков. 

В Ada недопустимы переменные в подпрограммах, но допустимы пара¬ 
метризованные блоки, содержащие параметры подпрограмм. Это решение 
удовлетворяет нашим требованиям, так как физический датчик размещается 
статически. Мы можем записать результат наших проектных решений на 
Ada следующим образом: 


with System_Classes; 
type Value is private; 

with procedure Notify_CIient (The_Value : in Value); 
with procedure Wam_Client (The_Value : in Value); 
with procedure Alert_Client (The_Value ; in Value); 
with function Scale (The_Raw_Value : In Integer) return Value; 

package Periodic_Sensor_Manager is 

type Sensor (Memory_Address : System_Classes.Address) is private; 


procedure Start (The_Sensor : in 

Frequency : in 

Wamming_High_Liniit ; in 

Waming Low Limit : in 

Alert_High_Limit : in 

Alert_Low_Limit : in 

procedure Stop (The_Sensor : in 

function Current_Value_Of (The_Sensor ; in Sensor) 

Sensor_Is_Already_Started : exception; 

Sensor_Failure : exception; 


Duration; 

Value; 

Value; 

Value; 

Value); 

Sensor); 


Value; 


end Periodic_Sensor_Manager; 


Мы предполагаем, что пакет System_Classes содержит соответствующее 
описание для дискретного типа Address, представляющего физическое разме¬ 
щение в памяти. Используя этот тип, мы можем описать тип Sensor с раз¬ 
личными величинами, представляющими порты ввода-вывода в карте памя¬ 
ти, связанной с этим датчиком. 

Так как это параметризованный блок, мы не можем использовать его 
непосредственно; мы должны обеспечить экземпляр для каждого типа датчи¬ 
ка, как это показано на рис. 12-8. Мы ожидаем, что архитекторы системы 
предоставят ряд стандартных экземпляров, которые другие разработчики бу¬ 
дут использовать непосредственно. Придуманный нами механизм работает 
лучше для циклических аналоговых датчиков и хуже для дискретных датчи¬ 
ков (таких, как переключатели) и для таких, которые регистрируют единич¬ 
ные, а не непрерывные события (такие, как сеанс связи автомобилей с ло¬ 
комотивом). Если наш анализ выявляет много таких датчиков, нам придется 
разработать сходный механизм и для них. 
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Рис. 12-8. Механизм датчиков. 

12.3. РАЗВИТИЕ 
Модульная архитектура 

Пакеты для больших систем необходимы, но в них недостаточно 
средств декомпозиции; следовательно, для решения этой проблемы мы долж¬ 
ны сосредоточиться на подсистемном уровне декомпозиции. Мы должны 
разработать модульную архитектуру системы управления движением, пред¬ 
ставляющую физическую структуру ее программного обеспечения. 

Проектирование программного обеспечения очень больших систем часто 
должно начинаться до полного завершения проектирования аппаратных 
средств. Оно и занимает больше времени. В любом случае интерфейс дол¬ 
жен быть разработан до того, как каждый завершит свои работы. Это озна¬ 
чает, что аппаратные и программные средства должны быть изолированы 
друг от друга настолько, насколько возможно, так чтобы проектирование 
программных средств можно было осуществлять без привязи к аппаратным 
средствам. Это означает также, что программное обеспечение должно быть 
заменяемым. В управляющих и контролирующих системах, таких, как сис¬ 
тема управления движением, мы должны быть заинтересованы в том, чтобы 
вводить новые аппаратные средства, которые могут появиться в процессе 
разработки программного обеспечения. 

Мы также должны на ранних этапах разумно провести декомпозицию 
программного обеспечения системы, чтобы субконтрактные работы над раз¬ 
личными частями системы могли проводиться одновременно (особенно если 
используются различные языки программирования). Как мы уже говорили в 
гл. 7, существует много нетехнических причин, определяющих физическую 
декомпозицию больших систем. Наиболее важным в этом случае является 
вопрос взаимодействия независимых групп разработчиков. Отношения субпод¬ 
рядчиков складываются обычно на достаточно ранних стадиях жизни систе¬ 
мы, часто до того, как получена достаточная информация для проведения 
правильной декомпозиции системы. Мы рекомендуем системным архитекто¬ 
рам провести несколько альтернативных декомпозиций подсистем для того, 
чтобы быть уверенным в правильности общих решений по физическому про¬ 
ектированию. Можно включить прототипирование в больших масштабах, 
но без подключения к прототипу реализации подсистем и моделирование за- 
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Рис. 12-9. Диаграмма модулей высшего уровня для системы управления 
движением. 



Рис. 12-10. Диаграмма модулей подсистемы Network Facilities. 

грузки процессора, маршрутизации сообщений и внешних событий. Прототи¬ 
пирование и моделирование могут послужить основой для нисходящего тес¬ 
тирования после создания системы. Как мы выбирали подходящую декомпо¬ 
зицию подсистемы? В гл. 4 показано, что объекты на высоком уровне 
обычно группируются в соответствии с их функциональным поведением. Еще 
раз отметим, что это не противоречит объектной модели, так как в термин 
«функциональный» мы не вкладываем понятие алгоритмической абстракции, 
включающей соответствие входа и выхода. Мы говорим, что функциональ¬ 
ность системы, которая представляет внешний вид и тестируемое поведение, 
является результатом совместной работы группы объектов. Таким образом, 
абстракция высокого уровня и механизмы, о которых мы говорили выше, 
являются хорошими кандидатами, вокруг которых организуются наши подси¬ 
стемы. Мы можем сначала допустить существование таких подсистем, а их 
интерфейс разработать через некоторое время. 
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Рис. 12-11. Диаграмма модулей подсистемы Databases. 



Рис. 12-12. Диаграмма модулей подсистем Devices. 

На диаграмме модулей (рис. 12-9) представлены проектные решения по 
организации верхнего уровня модульной архитектуры системы управления 
движением. Это высокоуровневая архитектура, каждый уровень которой со¬ 
ответствует функциям четырех подзадач, которые мы выделили выше: сеть 
передачи данных, база данных, аналоговые устройства управления в реаль¬ 
ном времени, человеко-машинный интерфейс. 

Спецификация подсистем 

Если мы рассмотрим внешнее представление любой из этих подзадач,то 
найдем, что все они обладают характеристиками объектов. Они уникальны, 
хоть и статичны, идентифицируемы; это создает большое количество состоя¬ 
ний и приводит к очень сложному поведению. Подсистемы используются как 
хранилища других классов, утилит классов и объектов; таким образом, они 
лучше всего характеризуются экспортируемыми ресурсами. На практике, при 
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использовании Ada эти ресурсы представляются в форме логической сово¬ 
купности компилируемых единиц, многие из которых упакованы. 

Диаграмма модулей на рис. 12-9 полезна, но не полна, так как каждая 
из подсистем на этой диаграмме слишком велика для реализации ее неболь¬ 
шим коллективом разработчиков. Мы должны раскрыть внутреннее 
представление подсистем верхнего уровня, а затем провести их декомпо¬ 
зицию. 

На рис. 12-10 показана диаграмма модулей подсистемы Network 
Facilities. Мы видим, что одна из подсистем собственная (Radio 
Communication), а другая экспортируется (Message). Собственный пакет 
скрывает детали программного управления физическими устройствами, в то 
время как экспортируемая подсистема обеспечивает спроектированный ранее 
механизм передачи сообщений. 

Подсистема, называемая Databases, построена на основе ресурсов подси¬ 
стемы Network Facilities и служит для реализации механизма планирования 
движения поезда, который мы создали выше. Как показано на рис. 12-11, 
подсистема Databases состоит из нескольких понятных частей. Мы видим, 
что подсистема Train-Plan Database экспортируется из Database, что позво¬ 
ляет сделать ее ресурсы доступными другим подсистемам, которые явно им¬ 
портируют их. Подсистема Train-Plan Database также строится на основе ре¬ 
сурсов двух собственных подсистем (Train Database и Track Database) и од¬ 
ной импортируемой подсистемы (Message). 

Затем подсистема Devices также естественно декомпозируется на не¬ 
сколько небольших подсистем. Как показано на рис. 12-12, мы решили 
сгруппировать программы, относящиеся по всем околопутевым устройствам, в 
одну подсистему, а программы, связанные с исполнительными механизмами 
и датчиками локомотива, в другую. Эти две подсистемы доступны клиенту 
подсистемы Devices, и обе построены на основе ресурсов, представляемых 
Train-Plan Database и Message. Таким образом, мы спроектировали подси¬ 
стему Devices для реализации механизма датчиков, который мы спроектиро¬ 
вали выше. 

Как показано на рис. 12-13, мы выбрали декомпозицию подсистемы 
верхнего уровня User Applications в несколько небольших подсистем, вклю¬ 
чая Engineer Applications и Dispatcher Applications, для отображения различ¬ 
ных долей двух главных пользователей системы управления движением. 
Подсистема Engineer Applications содержит ресурсы, которые обеспечивают 
все взаимодействия, специфицированные в требованиях человеко-машинного 
интерфейса, включая функции анализа системы сбора и отображения инфор¬ 
мации о состоянии локомотива и системы управления двигателем. Подсисте¬ 
ма Dispatcher Applications обеспечивает все функции интерфейса диспетчер- 
машина. Подсистемы Engineer Applications и Dispatcher Applications разделя¬ 
ют общие собственные ресурсы, экспортируемые из подсистемы Dispatcher, 
которая реализует механизм отображения, описанный нами выше. 

В результате проектирования мы получили четыре подсистемы верхнего 
уровня, окруженные десятью меньшими подсистемами, для которых мы име¬ 
ем все ключевые абстракции и механизмы, разработанные до этого. Важно, 
что эти подсистемы формируют блоки для присвоения имен и блоки для со¬ 
здания конфигурации управления и разработки различных версий. Даже на 
ранних стадиях проектирования мы можем начать создавать множество реа¬ 
лизаций, составляющих совместимые версии каждой подсистемы. Как мы го¬ 
ворили в гл. 7, разрабатывать подсистему может один человек, а реализовы- 
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ватъ многие. Разработчик детализирует проектирование и реализацию подси¬ 
стемы и управляет ее интерфейсом с другими подсистемами на том же 
уровне абстракции. Таким образом, управление разработкой очень больших 
проектов становится возможным, когда происходит декомпозиция сложных 
задач. 

Основой для выполнения этой работы является инженерное 
конструирование интерфейсов. После того как интерфейсы сконструированы, 
они должны тщательно сохраняться. Как мы определяем внешнее 
представление подсистемы? Для ответа на этот вопрос надо каждую подси¬ 
стему рассматривать как объект, т.е. мы ставим тот же вопрос, какой мы 
задавали в гл. 4 для значительно более простых объектов: какие состояния 
имеет объект, какие действия может выполнить клиент над ним, какие дей¬ 
ствия он требует от других объектов? 

Например, рассмотрим подсистему Train-Plan Database. Она строится на 
основе трех других подсистем Messages, Train Database, Track Database и 
имеет нескольких важных клиентов — подсистемы Wayside Devices, 
Locomotive Devices, Engineer Applications и Dispatcher Applications. Train-Plan 
Database имеет относительно простые состояния, особенно состояния всех 
планов поезда. Конечно, ненормально, что эта подсистема должна поддержи¬ 
вать поведение распределенного механизма планирования движением поезда. 
Итак, с внешней стороны клиент видит монолитную базу данных, но изнут¬ 
ри мы знаем, что на самом деле база данных распределенная, и поэтому 
должны разместить этот механизм над механизмом передачи сообщений в 
подсистеме Messages. 

Какие действия можно выполнять над Train-Plan Database? Выполнимы 
все обычные операции базы данных: добавление, удаление, изменение запи¬ 
сей и запросы о записях. В конце концов мы соберем все проектные реше¬ 
ния в форме пакетов Ada, которые составляют эту подсистему и обеспечи¬ 
вают описание всех ее операций. 

На этой стадии проектирования мы продолжаем процесс проектирования 
для каждой подсистемы. Еще раз отметим, что вероятность того, что эти 
интерфейсы окажутся правильными с первого раза очень мала. Как и для 
небольших объектов, опыт подсказывает, что большинство изменений, кото¬ 
рые мы произведем в интерфейсах, не затронут лежащие выше уровни, ес¬ 
ли допустить, что до этого мы правильно охарактеризовали каждую подси¬ 
стему в объектно-ориентированном стиле. 

12.4. ИЗМЕНЕНИЯ 
Добавление новых функций 

Старое программное обеспечение постоянно сопровождается и дорабаты¬ 
вается, что особенно справедливо для таких больших систем, как наша. 
Действительно, мы до сих пор находим используемые программы, разрабо¬ 
танные двадцать лет назад (которые по программным меркам являются пат¬ 
риархами). Чем больше пользователей применяют систему управления дви¬ 
жением и чем лучше мы адаптируем проект к новым реализациям, тем ча¬ 
ще клиенты будут находить новые неожиданные применения для существую¬ 
щих механизмов, создавая необходимость включения в систему новых функ¬ 
ций. Рассмотрим единственное добавление к нашим требованиям, называемое 
обработкой платежной ведомости. Предположим, анализ показал, что в веде- 



424 


Применения 



Рис. 12-13. Диаграмма модулей подсистемы User Applications. 

нии платежной ведомости железнодорожной компании участвует аппаратура, 
выпуск которой прекращен, и возник серьезный риск безвозвратной потери 
платежной ведомости в результате нескольких поломок в системе. В этом 
случае мы можем объединить обработку платежной ведомости с системой 
управления движением. Для начала несложно понять, как эти две несвязан¬ 
ные задачи будут решаться; мы можем рассмотреть их как разные приложе¬ 
ния, где обработка платежной ведомости работает в фоновом режиме. Даль¬ 
нейший анализ показывает, что может быть получена большая польза от 
обработки платежной ведомости. Вспомним, что план поезда содержит ин¬ 
формацию о распределении бригад. Отсюда мы можем проследить действи¬ 
тельные варианты запланированного распределения бригад и рассчитать за¬ 
траченное ими рабочее время, время переработки и т.п. Получая эту ин¬ 
формацию непосредственно, мы можем обрабатывать платежную ведомость 
дешевле и быстрее. Что надо сделать для добавления этой функции к наше¬ 
му уже существующему проекту? Наш подход заключается в том, чтобы 
можно было добавлять новые подсистемы в подсистему User Applications, 
представляющую функции обработки платежной ведомости. В данном месте 
архитектуры такой подсистеме будут видны все важные механизмы, которые 
служат для ее построения. Это действительно полностью объединенная, хо¬ 
рошо сконструированная объектно-ориентированная система; простые добав¬ 
ления, необходимые для системы, могут быть сделаны достаточно просто по¬ 
строением новых приложений на основе уже существующих механизмов. 
Предположим, мы хотим ввести более существенное изменение: ввести 
элементы экспертной системы, создав систему, помогающую диспетчеру, при 
прокладке маршрутов и предупреждающую об ошибках. Как это требование 
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отразится на нашем проекте? Незначительно. Мы размещаем новую подси¬ 
стему между подсистемами Train-Plan Database и Dispatcher Applications, так 
как база знаний, созданная для экспертной системы, подобна по содержанию 
Train-Plan Database; кроме того, подсистема Dispatcher Applications является 
единственным клиентом экспертной системы. Нам предстоит разработать не¬ 
который новый механизм, чтобы доводить рекомендации до конечного поль¬ 
зователя. Например, мы можем использовать архитектуру классной доски 
так, как мы это делали в гл. 11. 

Изменение аппаратных средств 

Мы уже говорили, что аппаратные средства развиваются быстрее, чем 
мы умеем создавать программное обеспечение. Поэтому рабочая аппаратура 
в больших системах заменяется гораздо раньше, чем программы. Например, 
после нескольких лет эксплуатации мы можем заменить дисплей на каждом 
поезде и каждом диспетчерском центре. Как это может повлиять на сущест¬ 
вующий проект? Если во время разработки проекта мы ограничили интер¬ 
фейсы подсистем на высоком уровне абстракции, эти изменения аппаратуры 
приведут к незначительным изменениям программ. Мы изменяем только со¬ 
вокупность программ, относящихся к данным дисплеям, но не для других 
подсистем, которые не были рассчитаны на особенности данных рабочих 
станций. Это достигается тем, что поведение всех рабочих станций скрыто в 
подсистеме Displays. Таким образом, эта подсистема действует как абстракт¬ 
ный пожарный, который защищает остальных клиентов от сложностей раз¬ 
нообразных дисплеев. Таким образом, радикальные изменения в стандартах 
коммуникации затронут реализацию, но только в ограниченной части. Наш 
проект гарантирует, что только подсистема, называемая Messages, знает о 
сетевой коммуникации. Таким образом, фундаментальные изменения в сети 
не отразятся ни на каком высокоуровневом клиенте; подсистема Messages 
защищает их от реального мира. Любые изменения, которые мы вводили, 
не смогли нарушить структуру созданного нами проекта. Это верный при¬ 
знак хорошо спроектированной объектно-ориентированной системы. 

Дополнительная литература 

Требования к системе управления движением основаны на расширенной 
системе управления железной дорогой, описанной в работе Murphy 
[С, 1988]. Трансляция и верификация сообщений появляются фактически во 
всех командах и управляющих системах. Plinta, Lee и Rissman [С, 1989] 
предложили проект механизма безопасного распространения сообщений в 
процессорах распределенных систем. Краткое изложение языка программиро¬ 
вания Ada с примерами приведено в приложении. 



Заключение 


Книги лишь частично рождаются умом и плотью своих 
создателей. Большая их часть возникает откуда-то еще, и 
авторы сидят у своих пишущих машинок в ожидании, ког¬ 
да «случится» книга. 


GUY LEFRANCOIS 
Of Children 


Объектно-ориентированное проектирование претендует на 
роль последнего слова в методологии проектирования, однако 
оно представляет собой сплав многих лучших идей в области 
создания сложных систем. Такие системы уже созданы в различ¬ 
ных предметных областях, а сам подход успешно использован 
как для задач в несколько сот строк кода, так и в 1-10 милли¬ 
онов строк. Пока нет экспериментальных (практических) доказа¬ 
тельств, что данная методология позволит реализовать системы 
объемом в десятки миллионов строк кода. Можно полагать, что 
развитие объектно-ориентированного проектирования приведет к 
тому, что будут созданы системы невообразимой сложности. 

Действительно, требования к уровню программных систем 
резко возрастают. Современные возможности аппаратных средств 
и общественная потребность в компьютеризации все более и бо¬ 
лее требуют расширения сферы автоматизации. Потенциальные 
возможности объектно-ориентированного проектирования, вклю¬ 
чая процедурные вопросы и документирование, дают свободу 
энергии человека и позволяют преодолеть препятствия на пути 
создания сложных систем. 



Приложения 

Объектные и объектно- 
ориентированные языки 
программирования 

Методология OOD не накладывает ограничений на использование како¬ 
го-либо одного языка программирования. В ней может быть применен широ¬ 
кий спектр объектных и объектно-ориентированных языков программирова¬ 
ния. Однако нельзя игнорировать особенности кодирования, определяемые 
языком. «Язык программирования выполняет три функции: 1) инструмент 
проектирования, 2) средство выражения мыслей программиста, 3) средство 
формирования инструкций для ЭВМ» [1 ]. Приложение предназначено для 
читателей, которые незнакомы с теми языками программирования, которые 
использованы в книге для описания примеров. Для каждого языка 
приведены краткое описание и некоторые важные особенности. 

П.1. Введение 

В настоящее время известно более 2000 различных языков программи¬ 
рования. Это объясняется тем, что каждый язык создавался исходя из конк¬ 
ретных требований определенных предметных областей. Кроме того, новые 
языки разрабатывались для решения все более и более сложных задач. 
Опыт применения языков программирования также отражается на представ¬ 
лениях о том, какие элементы языка более существенны или менее необхо¬ 
димы. На развитие языков программирования большое влияние оказали до¬ 
стижения в теории создания компьютерных систем, в частности способы 
формального описания операторов, модулей абстрактных типов данных и 
процедур. В гл. 2 говорилось о четырех поколениях языков программирова¬ 
ния, которые ориентированы на математические вычисления, алгоритмы, 
данные и объектно-ориентированные абстракции. Последние достижения в 
области развития языков программирования связаны с влиянием объектного 
подхода. Уже насчитывается более 100 различных объектных и объектно- 
ориентированных языков. Принято называть объектными языки, которые 
имеют механизмы реализации абстрактных данных и классов; объектно-ори¬ 
ентированными являются те объектные языки, в которых реализован меха¬ 
низм наследования как средство отражения иерархии классов. 

Общим предком практически всех используемых объектных и объектно- 
ориентированных языков является язык Simula, созданный в 1960 г. Далом, 
Майхраугом и Нейгардом [2]. Язык Simula основывался на идеях языка 
ALGOL, но был дополнен механизмом наследования и ограничения доступа. 
Кроме того, Simula — язык, который ориентирован на описание систем и 
их прототипирование и имеет строгую дисциплину написания программ, от¬ 
ражающую словарь предметной области. 

На рис. П-1 показаная генеалогия демонстрирует генеалогию пяти наи¬ 
более представительных и распространенных языков программирования объ¬ 
ектного и объектно-ориентированного направления: Smalltalk, Object Pascal, 
C++, CLOS и Ada. Эти языки выбраны для примеров реализации объектного 
подхода благодаря их значимости в процессе создания сложных систем. 



Рис. П-1. Генеалогия объектных и объектно-ориентированных языков 
программирования. 

П.2. ЯЗЫК SMALLTALK 
Основные положения 

Язык Smalltalk разработан участниками группы исследовательского цент¬ 
ра фирмы Xerox в Palo Alto как элемент программы фантастического проек¬ 
та Dynabook Алана Кая (Alan Kay). В основу языка Smalltalk были положе¬ 
ны идеи языка Simula, а также языка FLEX и разработки Сеймора Паперта 
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и Валласа Фыорзича (Seymore Papert, Wallace Feurzeig). Smalltalk является 
одновременно языком программирования и программной оболочкой. Это «чи¬ 
стый» объектно-ориентированный язык, в котором все рассматривается в ви¬ 
де объектов, включая целые числа и классы. Smalltalk, как и язык Simula, 
является наиболее представительным объектно-ориентированным языком, по¬ 
скольку он оказал влияние не только на последующие поколения языков 
программирования, но и на принципы построения графического интерфейса 
пользователя (например, на наиболее популярные сегодня средства визуали¬ 
зации Macintosh и Motif). 

Работа над языком Smalltalk продолжалась почти 10 лет. Главным ар¬ 
хитектором проекта Smalltalk на протяжении всей работы был Дэн Ингалс 
(Dan Ingalls), но значительный вклад в него внесли также Питер Дейтч, 
Глен Краснер и Ким Мак-Колл (Peter Deutsch, Glenn Krasner, Kim McCall). 
Элементы оболочки Smalltalk разрабатывались параллельно Джеймсом Альт- 
хофом, Робертом Флеганом, Тедом Кехлером, Дианой Мерри и Стивом Рут- 
цом (James Althoff, Robert Flegal, Ted Kaehler, Diana Merry и Steve Rutz). 
Важную роль в проекте играли также Адель Гольдберг и Девид Робсон 
(Adele GoldBerg, David Robson), которые вели учет по ходу проектирования. 
Известно пять реализаций языка Smalltalk: Smalltalk-72, -74, -76, -78, -80 
(цифры обозначают год создания). Реализации Smalltalk-72, -74 заложили 
основу языка, но не имели механизма наследования. 

В последующих версиях был введен общий суперкласс и завершено 
формирование идеи о том, что все элементы языка должны быть объектами. 
Smalltalk-80 реализован на многих классах ЭВМ и является сегодня коммер¬ 
ческим продуктом в первую очередь для персональных компьютеров и рабо¬ 
чих станций. 

Обзор 

По утверждению Ingalls: «Цель проекта Smalltalk состоит в том, чтобы 
сделать мир информации доступным даже для детей любого возраста. Вся 
трудность состоит в том, чтобы найти и использовать достаточно простые и 
эффективные средства, которые позволят отдельному человеку свободно опе¬ 
рировать самой разной информацией от — простых чисел и текста до зву¬ 
ковых и зрительных образов» [4 ]. Основу языка составляют две простые 
концепции: 1) все рассматривается в качестве объектов; 2) объекты взаимо¬ 
действуют путем обмена сообщениями. 

В табл. П-1 сведены характеристики языка Smalltalk, имеющие отноше¬ 
ния к семи основным элементам объектного подхода. Множественное насле¬ 
дование не отмечено в таблице, но может быть реализовано путем переоп¬ 
ределения некоторых простых методов [5]. 

Пример 

Рассмотрим задачу с однородным списком изображений в виде окружно¬ 
сти, прямоугольника или закрашенного прямоугольника (аналогично задаче, 
приведенной в гл. 3). В обширной библиотеке Smalltalk уже определены 
классы для окружности и прямоугольника, поэтому решение задачи упроща¬ 
ется. Это роль повторного использования компонент. Однако для удобства 
сравнения предположим, что в нашем распоряжении есть только примитивы 
для линии и дуги окружности. Определим класс AShape следующим образом: 
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Таблица П-1. Характеристики языка Smalltalk 


Абстракции 

Переменные объектов 

Да 


Методы объектов 

Да 


Переменные классов 

Да 


Методы классЬв 

Да 

Ограничение 

Для переменных 

Обособленные 

доступа 

Для методов 

Общедоступные 

Модульность 

Виды модульности 

Отсутствует 

Иерархия 

Наследование 

Простое 


Обобщенные блоки 

Нет 


Метаклассы 

Да 

Типирование 

Строгое типирование 

Нет 


Полиморфизм 

Да (простой) 

Параллельность 

Многозадачность 

Да (определяется 



в классе) 

Устойчивость 

Устойчивость объектов 

Нет 


Object subclass: #AShape 

instanceVariableNames: ’theCenter’ 
dassVariableNames: ” 
poolDictionaries: ” 
category: ’Appendix’ 


«Initialize the shape» 
theCenter <— Point new 
setCenten aPoint 

«Set the center of the shape» 
theCenter <— aPoint 
center 

«Return the center of the shape» 
^theCenter 

draw 

«Draw the shape» 
self subclassResponsibility 
Теперь определим класс ACircle: 

AShape subclass: #ACirde 

instanceVariableNames: ’theRadius' 
dassVariableNames: ” 
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poolDictionaries: ” 
category: ’Appendix’ 
setRadius: anlnteger 

«Set the radius of the circle» 

theRadius <— anlnteger 

«Return the radius of the circle* 


^theRadius 


«Draw the circle» 

anArc <— Arc new. 
index <— 1. 

[index <- 4] 
whileTrue: 

[anArc 

center: theCenter 
radius: theRadius 
quadrant: index. 
anArc display, 
index <— index + 1] 

Далее введем класс ARectangle: 

AShape subclass: «ARectangle 

instanceVariableNames: ’theWidth’ 
classVariableNames: ” 
poolDictionaries: ” 
category: ’Appendix’ 

setHeighb anlnteger 

«Set the height of the rectangle» 

theHeight <— anlnteger 
setwidth: anlnteger 

«Set the width of the rectangle» 

theWidth <— anlnteger 
height 

«Return the width of the rectangle» 
''theHeight 

width 

«Return the width of the rectangle» 


'theWidth 
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«Draw the rectange» 

I anLine upperLeftCorner I 
anLine <— Line new. 

upperLeftCorner <-theCenter x — (theWidth / 2) @ (theCenter у — (theHeight / 2)). 
aLine beginPoint: upperLeftCorner. 

aline endPoint: upperLeftCorner x + theWidth (ffi upperCorner y. 
aLine display. 

aLine beginPoint: aLine endPoint. 

aLine endPoint: upperLeftCorner x + theWidth @ (upperCorner у + theHeight). 
aLine display. 

aLine beginPoint: aLine endPoint. 

aLine endPoint: upperLeftCorner x @ (upperCorner у + theHeight). 
aLine display. 

aLine beginPoint: aLine endPoint. 
aLine endPoint: upperLeftCorner. 
aLine display 

Подкласс ASolidRectangle опишем следующим образом: 

Arectangle subclass: «ASolidRectangle 
instanceVariableNames: ” 
classVariableNames: ” 
pooIDictionaries: ” 
category: ’Appendix’ 


«Draw the solid rectange* 

I upperLeftCorner lowerRightCorner I 
super draw. 

upperLeftCorner <— theCenter x - (theWidth guo: 2) + 1 @ 

(theCenter у — (theHeight quo: 2) + 1). 
lowerRigthComer <— upperLeftCorner x + theWidth — 1 @ 

(upperLeftCorner у + theWidth — 1). 

Display 

fill: (upperLeftCorner comer: lowerRightCorner) 
mask: Form gray 

Литература 

Основными руководствами по языку Smalltalk являются документы по 
Smalltalk-80: «The Language» Goldberg и Robson [6]; «The Interactive 
programming EnviRonment» Goldberg [7); «Bit of History», «Words of Advice» 
Krasner [8]. 

П.З. ЯЗЫК OBJECT PASCAL 
Основные положения 

Язык Object Pascal создавался сотрудниками фирмы Apple Computer 
(некоторые из них были участниками проекта Smalltalk) совместно с Никла- 
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усом Виртом (Niklaus Wirth) — создателем языка Pascal. Непосредственным 
предшественником Object Pascal является Clascal (объектно-ориентированная 
версия Pascal для проекта Lisa). Object Pascal известен с 1986 г. и является 
первым объектно-ориентированным языком программирования, который на¬ 
шел поддержку у программистов-пользователей Macintosh (MPW) и послу¬ 
жил основой для создания оболочки компьютеров семейства Apple. Для 
MPW создана библиотека классов, называемая МасАрр и являющаяся осно¬ 
вой для прикладных задач в соответствии с требованиями к интерфейсу 
пользователя Macintosh. 


Таблица П-2. Характеристики языка Object Pascal 


Абстракции 

Переменные объектов 

Методы объектов 

Переменные классов 

Методы классов 

Да 

Да 

Нет 

Нет 

Ограничение 

Для переменных 

Общедоступные 

доступа 

Для методов 

Общедоступные 

Модульность 

Виды модульности 

Модуль 

(интерфейс- 

реализация 

Иерархия 

Наследование 

Простое 


Обобщенные блоки 

Нет 


Метаклассы 

Нет 

Типирование 

Строгое типирование 

Да 


Полиморфизм 

Да (простой) 

Параллельность 

Многозадачность 

Нет 

Устойчивость 

Устойчивость объектов 

Нет 


На основе Object Pascal впоследствии созданы еще две версии объектно- 
ориентированного Pascal: Quick Pascal (фирмы Microsoft) и Turbo Pascal 5.x 
(фирмы Borland). 

Обзор 

Шмаккер утверждает, что «Object Pascal — «обглоданный» объектно- 
ориентированный язык. В нем отсутствуют методы класса, переменных клас¬ 
са, множественного наследования и метаклассов. Эти механизмы исключены 
специально, чтобы сделать язык простым для изучения программистами, на¬ 
чинающими изучать объектно-ориентированную методологию» [9]. В 
табл. П-2 приведены общие характеристики Object Pascal. 

Пример 

Принято размещать интерфейсную часть и реализацию классов в языке 
Object Pascal в разных файлах. Это связано с тем, что Object Pascal допу- 

28 Гради Буч 
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скает раздельную компиляцию внешней и внутренней частей программного 
блока. Для задачи, связанной с выводом изображений, приведем интерфейс¬ 
ную часть классов: 

unit UShales; interface 


иМасЛрр, UPrinting, I Dialog, ToolUtils, Packages, UMacAppUtilitics; 

type 

TShape - object (TObject) 
fCenter Point; 
procedure IShape; 

procedure SetCenter (TheCenter: Point); 
procedure Draw; 


function Center: Point; 


TCircle - object (TShape) 
fRadius: Integer; 

procedure IShape; override; 

procedure SetRadius (TheRadius: Integer); 

procedure Draw; override; 

function Radius: Integer; 


TRectangle - object (TShape) 

Weight: Integer; 
fWidth: Integer; 


procedure IShape; override; 
procedure SetHeight (Thelleight: Integer); 
procedure SetWidth (TheWidth : Integer); 
procedure Draw; override; 

function Height: Integer; 
function Width: Integer; 


end; 

TSoiidRectangie - object (TRectangle) 
procedure Draw; override; 


implementation 

{$1 UShapes.incl.p} 
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Отметим, что, несмотря на отсутствие формального ограничения доступа 
в Object Pascal, все поля предполагаются обособленными, а доступ к ним 
осуществляется через методы класса. В о і дельном файле опишем реализа¬ 
цию классов с использованием графических средств библиотеки QuickDraw: 

procedure TShape.IShape; 
var 

APoint: Point; 

begin 

SetPt (APoint, 0, 0); 

(Center APoint; 

end; 

procedure TShape.SetCenter (TheCenter : Point); 
begin 

fCenter TheCenter; 


procedure TShape.Draw; 

function TShape.Center : Point; 
begin 

Center fCenter; 

end; 

procedure TCircle.IShape; override; 
begin 

inherited IShape; 

(Radius 0; 


procedure TCirde.SetRadius (TheRadius ; Integer); 
begin 

(Radius TheRadius; 

end; 

procedure TCircle.Draw; override; 
var 

ARect : Rect; 

begin 

PenNormal; 

SetRect (ARect, (Center.h, (Center.v, fCenter.h, (Center.v); 
InsetRect (ARect, -(Radius, -(Radius); 

FrameOval (ARect); 

end; 

function TCircle.Radius : Integer; 
begin 

Radius (Radius; 

end; 

procedure TRectangle.IShape; override; 
begin 

inherited IShape; 
fHeight 0; 
fWidth 0; 

end; 

procedure TRectangle.SetHeight (TheHeight : Integer); 
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begin 

fHeight TheHeight; 

end; 

procedure TRectangle.SetWidth (TheWidlh : Integer); 
begin 

fWidth TheWidth; 

end; 


procedure TRectangle.Draw; override; 

ARect : Rect; 

begin 

PenNormal; 

SetRect (ARect, fCenter.h, fCenter.v, fCenter.h, fCenter.v); 

InsetRect (ARect, -round(fWidth / 2), -round((Height / 2)); 

FrameRect (ARect); 

end; 

function TRectangle.Height : Integer; 
begin 

Height fHeight; 

end; 

function TRectangle.Width : Integer; 
begin 

Width fWidth; 

end; 

procedure TSolidRectangle.Draw; override; 

ARect : Rect; 

begin 

interited Draw; 

SetRect (ARect, fCenter.h, fCenter.v, fCenter.h, fCenter.v); 

InsetRect (ARect, (1 — round(fWidth / 2)), (1 — round (fHeight / 2))); 
FillRert (ARect, Gray); 


Литература 

Основным руководством no Object Pascal может служить Macintosh 
Programmer’s Workshop Pascal 3.0 Reference [10]. 

П.4. Язык C++ 

Основные положения 

Язык программирования C++ разработан сотрудником Bell Laboratories 
компании AT&T Берном Страустрапом (Bjarne Stroustrup). Непосредственным 
предшедственником языка C++ является язык С with Classes, созданный тем 
же автором в 1980 г. Язык С with Classes в свою очередь был создан на 
основе языков С и Simula. C++ — это в значительной степени надстройка 
над С. В определенном смысле C++ можно назвать «улучшенным С», кото¬ 
рый обеспечивает контроль типов, перегрузку функций (переопределение) и 
ряд других свойств. Но главное состоит в том, что C++ ориентирован на 
объектное проектирование. 
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Известны две версии C++: 1.0 и 2.0. В версии 1.0 реализованы основ¬ 
ные механизмы объектно-ориентированного программирования, такие, как 
простое наследование и полиморфизм, контроль типов и переопределение 
функций. В созданной в 1989 г. версии 2.0 нашли отражение многие допол¬ 
нительные свойства (например, множественное наследование), полученные из 
опыта работы и обмена информацией с пользователями языка. В последую¬ 
щих версиях предполагается реализовать обобщенные модули (шаблоны) и 
обработку исключительных ситуаций. 

Первые трансляторы C++ на основе препроцессора для языка С, назван¬ 
ного cfront. Промежуточный код С мог быть использован в любых Unix сис¬ 
темах. В настоящее время почти для всех типов ЭВМ созданы специальные 
компиляторы C++. 

Обзор 

Страустрап утверждает, что «C++ создавался с целью избавить автора и 
его друзей от необходимости программировать на ассемблере, С или других 
языках высокого уровня. Основной задачей было создание языка, на котором 
удобно писать хорошие программы и приятно работать программисту. Язык 
C++ никогда не проектировался на бумаге. Одновременно выполнялось его 
проектирование, документирование и реализация» [11]. C++ устранил многие 
недостатки С, добавив механизмы описания классов, контроль типов, пере¬ 
определение функций, управление свободной памятью, постоянные типы, 
макроопределения (подставляемые функции), производные классы и вирту¬ 
альные функции [12]. 

Характеристики C++ приведены в табл. П-3. 

Пример 

Вернемся снова к задаче вывода изображений. В языке C++ принято 
описывать интерфейсную часть классов в заголовочных файлах. Поэтому на¬ 
пишем: 


struct Poin {Int X; Int Y;}; 

class Shape { 

public: 

Shape 0; 

void SetCenter (Point ACenter); 
virtual void Draw 0 - 0; 

Point Center 0; 

private: 

Point TheCenter; 


class Circle : public Shape { 
public: 

Circle 0; 

void SetRadius (int Anlnteger); 
virtual void Draw (); 
int Radius 0; 

private: 

int TheRadius; 


class Rectangle : public Shape { 
public: 
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Таблица П-3. Характеристики языка C++ 



Іпі Height О; 
ім Width О; 

private: 

int TheHeigh; 
int TheWidth; 


class SolidRectangle : public Rectangle { 
public: 

virtual void Draw (); 


Определения C++ не используют библиотеку классов. Предположим, что 
существуют программный интерфейс с X Windows и соответствующие ему 
объекты Display, Window, Graphics_Context. В отдельном файле напишем ре¬ 
ализацию методов, перечисленных в заголовочном файле: 

Shape::Shape О { 

TheCenter.X - 0; 

TheCenter.Y - 0; 

}; 
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void Shape::SetCenter (Point ACenter) { 
The Center - ACenter, 


Point Shape-Center () { 

return TheCenter, 

>; 

Circle-Circle 0 { 

TheRadlus - 0; 

>; 

void Clrcle::SetRadiu8 (int Anlnteger) { 



void Circle::Draw 0 { 

int X - (Center 0 .X — TheRadlus); 
int Y - (Center О .Y — TheRadius); 

XDrawArc (Display, Window, GraphicsContext, X, Y, 

(TheRadius • 2), (TheRadius * 2), 0, (360 • 64)); 

}; 


int Circle::Radius 0 { 

return TheRadius; 

}; 


Rectangle-Rectangle 0 { 

TheHeight - 0; 

TheWidth - 0; 

>; 

void Rectangle::SetHeight (int Anlnteger) { 

TheHeight - Anlnteger, 

>; 

void Rectangle-SetWidth (int Anlnteger) { 

TheWidth - Anlnteger; 

>; 

void Rectangle-Draw () { 

int X - (Center О .X — TheWidth / 2)); 
int Y - (Center () .Y — TheHeight / 2)); 

XDrawRectangle (Display, Window, GraphicsContext, X, Y, TheWidth, TheHeight); 

}; 


int Rectangle::Width 0 { 
return TheWidth; 

}; 


void SolidRectangle::Draw 0 { 

Rectangle::Draw 0; 

int X - (Center О .X — Width 0 /2)); 
int Y - (Center 0 .Y — HeightO / 2)); 
gc OldGraphicsContext - GraphicsContext; 

XSetForeground (Display, GraphicsContext, Grey); 

XDrawFilled (Display, Window, GraphicsContext, X, Y, Width», HeightO); 
GraphicsContext - OldGraphicsContext; 

): 
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Литература 

Основным пособием по C++ является: UNIX System V AT&T C++ 
Language System, Release 2.0 Product Reference Manual [13]. Кроме того, 
Selected Readings [14], Release Notes [15] и Library Manual [16]. 

П.5. ЯЗЫК COMMON LISP OBJECT SYSTEM (CLOS) 
Основные положения 

В языке Lisp существует несколько десятков диалектов, включая 
Maclisp, Standard Lisp, SpiceLisp, S-l Lisp, ZetaLisp, Nil, InterLisp и Scheme. 
В начале 80-х годов под воздействием идей объектно-ориентированного про¬ 
граммирования возникла серия новых диалектов Lisp, многие из которых 
были ориентированы на представление знаний. Успех Ги Стила (Guy Steele) 
в стандартизации Common Lisp способствовал попытке стандартизировать 
объектно-ориентированные диалекты в 1986 г. Идея стандартизации была 
поддержана летней конференцией 1986 г. по ACM Lisp и функциональному 
программированию, в результате чего была создана специальная рабочая 
группа при комитете X3J13 ANSI (Комитет по стандартизации Common 
Lisp). 


Таблица А-4. CLOS 


Абстракции 

Переменные объектов 

Да 


Методы объектов 

Да 


Переменные классов 

Да 


Методы классов 

Да 

Ограничение 

Для переменных 

Чтение, запись. 

доступа 

Для методов 

доступ 

Общедоступные 

Модульность 

Виды модульности 

(монолитный) 

Иерархия 

Наследование 

Множественная 


Обобщенные блоки 

Нет 


Метаклассы 

Да 

Типирование 


Возможно 


Полиморфизм 

Да 

(множественный) 

Параллельность 

Многозадачность 

Да 

Устойчивость 

Устойчивость объектов 

Косвенно 


Поскольку новый диалект должен был стать надстройкой к Common 
Lisp, он получил название Common Lisp Object System (сокращенно CLOS). 
В комитет вошли Боб Матис и Ги Стил (Bob Mathis, Guy Steele). Возгла- 
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вил комитет Дэниел Бобров (Daniel Bobrow), а его членами стали Соня 
Кин, Линда де Мишель, Патрик Дассуд, Ричард Габриель, Джеймс Кемпф, 
Грегор Кицазлес и Девид Мун (Sonya Keene, Linda de Michiel, Patrick 
Dussud, Richard Gabriel, James Kempf, Gregor Kicazles, David Moon). 

Серьезное влияние на проект CLOS оказали языки NewFlavors и 
CommonLoops. После двухлетней работы в 1988 г. была опубликована пол¬ 
ная спецификация CLOS. 

Обзор 

Кин (Keene) отмечает, что в проекте CLOS ставились три основные 
цели: 

* «Представление стандартного расширения языка, включающего все наибо¬ 
лее полезные приемы OOD. 

* Обеспечение эффективного и гибкого интерфейса программиста, позволяю¬ 
щего реализовать самые различные задачи. 

* Проект CLOS должен быть открытым для дальнейшего совершенствования 
и учета требований пользователя ООР» 117]. 

Обзор характеристик CLOS можно найти в табл. П-4. Не поддерживая 
прямо механизм устойчивости, CLOS имеет расширение с протоколом мета- 
обьектов для реализации этого механизма [18]. 

Пример 

В качестве примера рассмотрим снова задачу вывода изображений. На¬ 
чнем с определения классов: 

(defclass point О 

((х :initarg :х : accessor х :type integer) 

(у :initarg :у :accessor у :type integer))) 

(defclass shape 0 

((center :initarg :center :accessor center :type point))) 

(defclass rectangle (shape) 

((height dnitang :height :accessor height :type integer) 

(width :initang :width taccessor width :type integer))) 

(defclass solid-rectangle (rectangle) 

0) 

(defclass circle (shape) 

((radius :initang :radius :accessor radius :type integer))) 

Приведем методы для прямоугольника: 

(defmethod left ((r rectangle)) 

(— (x (center r)) (/ (width r) 2))) 

(defmethod right ((r rectangle)) 

(— (x (center r)) (/ (width r) 2))) 

(defmethod top ((r rectangle)) 

(— (x (center r)) (/ (height r) 2))) 


(defmethod bottom ((r rectangle)) 

(— (x (center r)) (/ (height r) 2))) 



Данное описание не использует библиотеку классов. Допустим существо¬ 
вание программного протокола с ресурсами, аналогичными Object Pascal 
QuickDraw, включая рисование линий, дуг и штриховку области. Введем 
также класс windows, обозначающий изображение на дисплее. Теперь напи¬ 
шем следующие методы: 

(deFgeneric draw (shape surface)) 

(defmethod draw ((s shape) window) 0) 

(defmethod draw ((r rectangle) window) 

(draw-line window (left r) (bottom r) (left r) (top r)) 

(draw-line window (left r) (bottom r) (right r) (bottom r)) 

(draw-line window (right r) (bottom r) (right r) (top r)) 

(draw-line window (left r) (top r) (left r) (top r)) 

(defmethod draw :after ((sr solid-rectangle) window) 

(fill-area window ‘gray-shade* (left sr) (bottom sr) (right sr) (top sr))) 

(defmethod draw ((c circle) window) 

(draw-arc gw (center c) (radius c) 0 360)) 


Литература 

Основным руководством no CLOS может служить Common Lisp Object 
Specification [19]. 

П.6. ЯЗЫК ADA 
Основные положения 

Министерство обороны США, вероятно, имеет самое большое число 
компьютеров во всем мире. В середине 70-х годов его программисты 
оказались в критической ситуации: проекты не укладывались в установлен¬ 
ные сроки и бюджет, а заданных характеристик не удавалось реализовать. 
Стало очевидно, что ситуация может только ухудшаться, поэтому министер¬ 
ство обороны финансировало проект создания единого языка высокого уров¬ 
ня. В этом смысле язык Ada является одним из первых языков программи¬ 
рования промышленного уровня. Исходные требования были сформулированы 
в 1975 г. в документе Стилмана (Steelman) и реализованы в 1978 г. Был 
объявлен международный конкурс, на который откликнулось 17 участников, 
и был выбран один проект, в реализации которого участвовали сотни уче¬ 
ных всех стран мира. 

Проект-победитель вначале носил условное наименование Green (ано¬ 
нимное кодовое название), а позднее получил имя Ada в честь Ada 
Augusta, графини Lovelace, которая известна по ее предсказаниям относи¬ 
тельно будущего компьютеризации. Основным разработчиком языка был 
Джоан Ичбиан (Jean Ichbian) из Франции. В команду разработчиков входи¬ 
ли: Bemd Krieg-Brueckner, Brian Wichmann, Henry Ledgard, Jean-Claude 
Heliard, Jean-Loup Gailly, Jean-Raymond Abrial, John Barnes, Mike Woodger, 
Olivier Roubine, S.A. Schuman и S.C. Vestal. 

Непосредственными предшедственниками Ada являются Pascal и его 
производные, включая Euclid, Lis, Mesa, Modula и Sue. Были использованы 
некоторые идеи ALGOL-68, Simula, CLU и Alphard. Стандарт ANSI для Ada 
был окончательно сформирован в 1983 г. Трансляторы Ada реализованы для 
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всех основных архитектур ЭВМ, использующих наборы инструкций. Язык 
Ada в настоящее время используется во многих государственных и коммер¬ 
ческих проектах (например, проект совместной европейско-американской кос¬ 
мической станции). Стандарты ANSI пересматриваются каждые пять лет, пр- 
этому в настоящее время действует проект Ada 9х. Исходные определения 
языка со временем изменились для обеспечения большей ясности, для устра¬ 
нения деффектов и исправления ошибок. В настоящем виде Ada является 
объектным, но не объектно-ориентированным языком. Однако есть множество 
предложений по расширению языка Ada до уровня объектно-ориентированно¬ 
го. 


Таблица П-5. Характеристики языка Ada 


Абстракции 

Переменные объектов 

Да 


Методы объектов 

Да 


Переменные классов 

Нет 


Методы классов 

Нет 

Ограничение 

Для переменных 

Общедоступные, 

доступа 


обособленные 


Для методов 

Общедоступные, 



обособленные 

Модульность 

Виды модульности 

Пакет 



(спецификация-тело) 

Иерархия 

Наследование 

Нет 


Обобщенные блоки 

Да 


Метаклассы 

Нет 

Типирование 

Строгое типирование 

Да 


Полиморфизм 

Нет 

Параллельность 

Многозадачность 

Да (определяется 



в языке) 

Устойчивость 

Устойчивость объектов 

Нет 


Обзор 

Перед разработчиками Ada стояли три важные цели: 

* Надежность и эксплуатационные качества программ. 

* Программирование — это деятельность человека. 

* Эффективность [20]. 

В табл. П-5 приведены основные характеристики языка Ada с точки 
зрения объектного подхода. 

Пример 

Рассмотрим снова задачи вывода изображений. Для языка Ada принято 
описывать классы в спецификации пакета. В нашем примере каждый класс 
размещается в отдельном пакете: 



Приложения 


package Points is 

type Point is record 
X : Natural; 
Y : Natural; 
end record; 

end Points; 


with Points; 
package Circle is 

type Circle is private; 

procedure Set_Center (The_Cenler : in out Circle; The_Center : in Point); 

procedure Set_Radius (The_Center : in out Circle; The_Radius ; in Natural); 

procedure Draw <The_Center : in Circle); 


function Center_Of (The_Circle : in Circle) return Point; 
function Radius_Of (The_Circle : in Circle) return Natural; 

type Circle is record 

Center : Point; 

Radius ; Natural; 
end record; 
end Circle; 


with Points; 
package Rectangle is 


type Rectangle (Is_Solid : Boolean False) 




procedure Set_Center 


(The_Rectangle ; in out Rectangle; 
The_Center ; in Point); 


procedure SetJHeight 


(The_Rectangle 

The_Height 


: in out Rectangle; 
: in Natural); 


procedure Set_Width 
procedure Draw 


(The_Rectangle : in 

The_Width : in 

(The_Rectangle : in 


Rectangle); 
Natural); 
Rectangle); 


function Center_Of (The_Rectang!e 
function Height_Of (The_Rectangle 
function Width_Of (The_Rectangle 


in Rectangle) return Point; 
in Rectangle) return Natural; 
in Rectangle) return Natural; 




type Rectangle (Is_Solid ; Boolean is 
Center : 
Height : 
Width : 


record 

Point; 

Natural; 

Natural; 


end Rectangles; 


end record; 


Реализация пакетов выполнена на основе связи языка Ada с XWindows 
с помощью глобальных переменных Display, Window, Graphics_Context: 


procedure Set_Center (The_Circle : in out Circle; The_Center : in Point) is 
begin 

The_Circle.Center The_Center; 
end Set_Center; 
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procedure Set_Radius (The_Circle : in out Circle; The_Radius ; in Natural) is 
begin 

The_Circle.Radius The_Radius; 
end Set_Radius; 

procedure Draw (The_Circle ; in Circle) is 

X : Integer The_Circle.Center.X — The_Circle.The_Radius; 

Y : Integer The_Circle.Center.Y — The_Circle.The_Radius; 

begin 

X Draw Arc (Display, Window, Graphics_Context, X.Y, 

(The_Circle.The_Radius * 2), <The_Circle.The_Radius » 2), 
0, (360 ♦ 64)); 

end Draw; 


function Center_Of (The_Cirde : in Circle) return Point is 

return The_Circle.Center; 
end Center_Of; 

function Radius_Of (The_Circle : in Circle) return Natural is 
begin 

return The_Circle.Radius; 
end Radius_Of; 

procedure Set_Center (The_Rectangle : in out Rectangle; 

The_Center : in Point) is 

begin 

The_Rectangle.Center The_Center; 
end Set_Center; 

procedure Set_Height (The_Rectangle : in out Rectangle; 

The_Height ; in Natural) is 

begin 

The_Rectangle.Height The_Height; 
end Set_Height; 

procedure Set_Width (The_Rectangle : in out Rectangle; 

The_Width : in out Natural) is 

begin 

The_Rectangle.Width The_Width; 
end Set_Width; 

procedure Draw (The_Rectangle ; in Rectangle) is 

X : Integer The_Rectangle.The_Center.X — (The_Rectangle.The_Width; 

Y ; Integer The_Rectangle.The_Center.Y — (The_Rectangle.The_Height; 

Old_Graphics_Context : GC Graphics_Context; 

begin 

XDrawRectangle (Display, Window, Graphics_Context, X,Y, 

(The_Rectangle.The_Width, (The_Rectangle.The_Height); 
if The_Rectangle.Is_Solid then 

XSetForeground (Display, Graphics_Context, Grey); 

XDrawFilled (Display, Window, Graphics_Context, X,Y, 

The_Rectangle.The_Width, The_Rcctangle.The_Height); 
Graphics_Context Oid_Graphics_Context; 

end if; 
end Draw; 

function Center_Of (The_Rectangle : in Rectangle) return Point is 
begin 

return The_Rectangle.Center; 
end Center_Of; 

function Height_Of (The_Rectangle : in Rectangle) return Natural is 
begin 
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return The_Rectangle.Helght; 
end Helght_Of; 

function Width_Of (The_Rectangle : in Rectangle) return Natural is 
begin 

return The_Rectangle.Width; 
end Width_Of; 

Литература 

Основным руководством по языку Ada является Reference Manual for 
the Ada Programming Language [21 ]. 

П.7. ДРУГИЕ ЯЗЫКИ OOP 

В работе Саундерса (Saunders) [22] дан обзор более чем восьмидесяти 
языков OOP. Автор группирует эти языки по семи характеристикам [23]: 

* Воздействие Языки, поддерживающие механизм делеги¬ 

рования. 

* Параллельность Объектно-ориентированные языки, реализу¬ 

ющие параллельность. 

* Распределенность Наличие распределенных объектов. 

* Фреймовые структуры Реализация теории фреймов. 

* Смешение Расширения традиционных языков до 

уровня OOP. 

* Использование Smalltalk Диалекты Smalltalk. 

* Ориентация Область применения OOP. 

* Прочее Языки OOP, не относящиеся ни к одному 

из категорий. 

На рис. П-2 перечислены основные языки OOP, а в библиографии при¬ 
ведены соответствующие источники информации. 



Рис. П-2. Объектные и объектно-ориентированные языки программи¬ 
рования. 
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Англо-русский толковый словарь 
терминов по объектно- 
ориентированному подходу 

abstract class (абстрактный класс) — класс объектов, для которого не определены эк¬ 
земпляры объектов. Абстрактные классы вводятся для последующего дополнения в части струк¬ 
туры и поведения. Методическая частъ абстрактного класса обычно является неполной и требует 



общего сложного процесса функционирования. 
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Class diagram (диаграмма, схема классов) — одно из изобразительных средств объект¬ 
но-ориентированного проектирования, имеющее своей целью наглядно показать используемые 
классы и их взаимоотношение в процессе логического проектирования системы. 

Class Structure (структура классов) — способ отражения иерархического строения сис¬ 
темы. Это граф, вершины которого соответствуют классам, а другие — взаимоотношениям клас¬ 
сов. Структура классов для конкретной системы представляется в виде совокупности диаграмм 
(схем) классов. 

Class Utility (поддержка класса) — совокупность общедоступных процедур. 

Class variable (переменная, параметр класса) — фрагмент области данных, являющийся 
частью информации о состоянии данного класса объектов. Совокупность всех параметров данно¬ 

го класса образует структуру класса. Параметры класса являются единым для всех объектов, 
принадлежащих данному классу. 

Client (объект-пользователь) — объект, который использует ресурсы другого объекта (либо 
действуя под управлением второго, либо в зависимости от его состояния). 

concurrency (параллелизм) — свойство, допускающее одновременное существование ак¬ 
тивных и пассивных объектов. Это свойство является фундаментальным для объектной методо- 


COnCUITent Object (параллельный объект) — активный объект, связанный каналами уп¬ 
равления. 


constructor (конструктор) — процедура создания объекта и (или) инициализация его 
начального состояния. 


container class (сборный класс) — класс, объекты которого составлены из других объ¬ 
ектов. Сборный класс может состоять из ряда однородных объектов (объекта одного класса), 
либо разнородных (относящихся к разным классам). Сборные классы могут быть обобщенными 
или иметь параметры, обозначающие классы содержащихся объектов. 

destructor (деструктор) — процедура, которая делает состояние объекта неопределенным 
и (или) ликвидирует сам объект. 

dynamic binding (динамическая связь) — связь имени объекта с классом, которая ус¬ 
танавливается только в процессе динамического порождения (создания) объекта в рабочей про- 


encapsulation (ограничение доступа) — процесс защиты отдельных элементов объекта, 
не затрагивающий существенных характеристик объекта как целого. Защита в виде ограничения 
доступа обычно устанавливается как в отношении структуры объекта, так и в отношении его 
методического содержания. Понятие «ограничение доступа» обычно соответствует понятию «за¬ 
щита информации». Ограничение доступа является фундаментальным свойством объектного под - 


field (поле) — обозначает фрагмент данных о состоянии объекта, является частью его 
структуры и используется наряду с терминами «переменная объекта», «фрагмент объекта» и 
«слот» (instance variable, member object, slot). 

free Subprogram (общедоступная процедура) — процедура или функция, представляю¬ 
щая собой сложную операцию над объектом или объектами одного или различных классов. Та¬ 
кой процедурой может быть любая, не входящая в методическую часть какого-либо объекта 
процедура или функция. 

friend (общность) — возможность использования метода двумя и более объектами раз¬ 
личных классов, связанных отношениями общности. 




























510 Англо-русский толковый словарь терминов но объектно-ориентированному подходу 


function (функция) — в контексте анализа требований к системе обособленный, наблю¬ 
даемый и контролируемый фрагмент поведения. 

generic function (обобщенная функция) — какая-либо операция над объектом. Обоб¬ 
щенная функция может быть переопределена в производном подклассе, следовательно, ее реали¬ 
зация зависит от всей последовательности методических описаний и наследственной иерархии. 
Этот термин обычно соответствует термину «виртуальная функция» (virtual (unction). 

generic class (обобщенный класс) — класс, являющийся основой для порождения дру¬ 
гих (производных) классов с помощью дополнения другими классами, объектами и (или) опера¬ 
циями. Прежде чем будет создан какой-либо объект обобщенного класса, осуществляется замена 
его параметров конкретными значениями. Обычно обобщенные классы используются в качестве 
сборных классов. Понятия «обобщенный класс» и «параметризованный класс» (parameterized 
class) идентичны. 

hierarchy (иерархия) — ранжированная и (или) упорядоченная система абстракций. 
Двумя наиболее употребительными видами иерархии применительно к сложным системам явля¬ 
ются классификация (иерархия по номенклатуре и по типам) и структура объекта (иерархия 
составных частей). Архитектура сложных систем и их функционирование также могут представ¬ 
ляться иерархически. Иерархичность — фундаментальное свойство объектного подхода. 

identity (индивидуальность) — сущность объекта, отличающая его от всех других 


implementation (реализация) — внутреннее строение класса, объекта или модуля, учи¬ 
тывающее особенности его поведения. 

information hiding (защита информации) — обеспечение защиты всех элементов объ¬ 
екта. В большинстве случаев соответствует понятию «ограничение доступа» (encapsulation). 

inheritance (наследование) — такое соответствие между классами, когда один класс по¬ 
вторяет структуру или поведение другого (простое наследование) или других (множественное 
наследование) классов. Наследование устанавливает иерархию классов номенклатурного характе¬ 
ра (по типу), при которой подкласс (производный) наследует признаки одного или нескольких 
суперклассов (исходных). Подклассы обычно имеют дополненные или переопределенные струк¬ 
туру и поведение по отношению к исходным суперклассам. 

instance (экземпляр объекта) — конкретное представление (реализация), обладающее ха¬ 
рактеристиками состояния, поведения и индивидуальности. Структура и поведение сходных по 
сути экземпляров объекта описываются в общем для них классе. Соответствует понятию «объ¬ 
ект» (object). 

instance variable (переменная объекта) — фрагмент данных о состоянии объекта. Со¬ 
вокупность переменных объекта определяют его структуру. Совпадает с понятием «поле», «фраг¬ 
мент объекта» и «слот» (field, member object, slot). 

instantiation (наполнение объекта) — процесс конкретизации обобщенного или парамет¬ 
ризованного класса, в результате которого образуется класс, позволяющий порождать экземпля¬ 
ры объекта. 

interface (интерфейс) — внешние особенности класса, объекта или модуля, придающие 
ему абстрактную форму и одновременно скрывающие его внутреннее устройство и поведение. 

iterator (итератор) — операция, позволяющая взаимодействовать с частями объекта. 

key abstraction (ключевая абстракция) — класс или объект, являющийся частью сло¬ 
варя предметной области. 

levels Of abstraction (уровни абстракции) — относительное ранжирование абстракций 
в структуре классов и объектов, в архитектуре модулей и функций. В иерархии по составу 
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более высокий уровень абстракции представляют такие абстракции, которые составлены из дру¬ 
гих абстракций. В иерархии по номенклатуре (типам) более высокий уровень иерархии соответ¬ 
ствует наиболее общим абстракциям, а более низкий — специализированным (уточненным) абс- 

mechanism (механизм) — структура, в которой организовано совместное функциониро¬ 
вание объектов для обеспечения заданных целей. 

member function (функция-элемент) — операция над объектом, являющаяся частью 
описания класса. Все функции-элементы — операции, но не все операции — функции-элемен¬ 
ты. Понятие «функция-элемент» совпадает в большинстве случаев с понятием «метод» (method). 

member object (фрагмент объекта) — часть данных о состоянии объекта. Совпадает с 
понятиями «поле», «переменная объекта», «слот» (field, instance variable, slot). 

message (сообщение) — операция связи между объектами. Совпадает с понятиями «ме¬ 
тод» (method) и «действие» (operation). 

metaclaSS (метакласс) — класс, порождающий другие классы. 

method (метод) — операция над объектом, определяемая в описании класса. Не любая 
операция является методом. Совпадает с понятиями «сообщение» (message), «действие» 
(operation). В некоторых языках метод может бытъ переопределен в подклассах, а в других яв¬ 
ляется неизменяемой частью обобщенной функции или виртуальной функции. 

тІХІП (смешение) — введение в класс особого дополнительного метода, который обычно 
противоположен методу исходного класса. 

modifier (модификатор) — способ изменения состояния объекта. 

modularity (модульность) — свойство системы, связанное с возможностью декомпозиции 
ее на ряд тесно связанных модулей. Модульность — один из фундаментальных элементов объ¬ 
ектного подхода. 

module (модуль) — фрагмент кода, являющийся строительным элементом в структуре 
системы; программный блок, который содержит декларации, выраженные в соответствии с тре¬ 
бованиями языка программирования и реализующие классы и объекты системы. Как правило, 
модуль состоит из интерфейсной части и реализации. 


module architecture (модульная архитектура) — иерархия модулей, составляющих 
структуру системы. Это граф, вершины которого соответствуют 
ям модулей между собой. Модульная архитектура представляі 
диаграмм. 


monomonism (мономорфизм) 
которому имена (например, объя 
ого-либо класса. 


Object (объект) — конкретное 
; характеристиками состояния, ш 
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Object model (объектный подход, методология) — совокупность основополагающих прин¬ 
ципов, лежащих в основе объектно-ориентированного проектирования. Применительно к про¬ 
граммной продукции такими принципами являются: абстрагирование, защита информации, мо¬ 
дульность, иерархия, типизация, параллелизм и устойчивость. 

Object Structure (объектная структура) — иерархическая структура, построенная по 
принципу составных частей. Представляет собой граф, вершины которого соответствуют объек¬ 
там, а дуги — взаимоотношениям объектов. Для отражения такой структуры или ее частей ис¬ 
пользуются диаграммы объектов. 

object-based programming (объектное программирование) — методология программи¬ 
рования, основанная на представлении программы в качестве совокупности объектов, каждый из 
которых является реализацией определенного типа. Типы в свою очередь образуют иерархию, 

не связанную с принципом наследования. В таких программах типы могут рассматриваться как 
статические элементы, а объекты имеют более динамическую природу в рамках существующих 
статических связей и в соответствии с принципом мономорфизма. 

object-oriented analysis (объектно-ориентированный анализ) — методология анализа, 
при которой требования формируются на основе понятий классов и объектов, составляющих 
словарь предметной области. 

Object-Oriented decomposition (объектная декомпозиция) — процесс выделения в сис¬ 
теме фрагментов, соответствующих классам и объектам предметной области. Практическое при¬ 
менение методов объектно-ориентированного проектирования связано с объектной декомпозицией, 
при которой любая проблема должна рассматриваться как совокупность объектов, согласованно 
действующих в целях обеспечения заданных требований. 

Object-Oriented design OOD (объектно-ориентированное проектирование) — методоло¬ 
гия проектирования, соединяющая процесс объектной декомпозиции и приемы представления 
логической, физической, статической и динамической моделей проектируемой системы. В част¬ 

ности, к числу таких приемов относятся диаграммы классов, объектов, модулей и процессов. 

Object-Oriented programming OOP (объектно-ориентированное программирование) — 
методология реализации, основанная на представлении программы в качестве совокупности объ¬ 
ектов, каждый из которых является реализацией определенного класса, а классы образуют 
иерархию на принципах наследования. При этом классы являются статическими элементами, а 

объекты имеют динамическую природу в 'рамках динамических средств поддержки и в соответ¬ 

ствии с принципами полиморфизма. 

operation (действие) — определенное воздействие одного объекта на другой объект с 
целью вызвать соответствующую реакцию. Действия, которые можно оказать на объект, опреде¬ 
ляются либо в его методической части как функции-элементы либо относятся к числу общедо¬ 
ступных процедур. Соответствует терминам «сообщение» (message), «метод» (method). 

parameterized class (параметризованный класс) — базовый класс, служащий основой 
для образования других классов, путем замены в базовом классе параметров (параметризация 

другими классами, объектами и (или) действиями) на значения. Только после «наполнения» па¬ 

раметров такого класса их значениями он становится пригодным для создания (реализации) 
объектов. Обычно используется в качестве сборного класса и имеет такой же смысл, как тер¬ 
мин «обобщенный класс» (generic class). 

passive Object (пассивный объект) — объект, не имеющий собственных каналов уп¬ 
равления. 

persistence (устойчивость) — свойство объекта существовать во времени не зависимо от 
процесса, породившего данный объект и (или) в пространстве (перемещение объекта в памяти 
за пределы места порождения). Это один из основных элементов объектной методологии. 
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polymorphism (полиморфизм) — один из принципов теории типизации, состоящий в 
том, что имена (например, объявление переменных) могут соответствовать различным классам 
объектов, входящим в один суперкласс. Следовательно, один объект, отмеченный таким именем, 
может по-разному реагировать на некоторое множество действий. 

private (обособленный) — часть интерфейса какого-либо класса, объекта или модуля, за¬ 
крытая для доступа со стороны других классов, объектов и модулей (ограничение «видимости»). 

process architecture (архитектура процессов) — отражение физической структуры сис¬ 
темы а виде иерархии процессов. Представляет собой граф, вершины которого соответствуют 
процессорам и устройствам, а дуги — соединениям между ними. Для отражения архитектуры 
процессов используется диаграмма процессов. 

process diagram (диаграмма процессов) — один из приемов объектно-ориентированного 
проектирования, используемый для представления процессов. Отражает полностью или частично 
архитектуру процессов системы. 

protected (защищенный) — часть интерфейса какого-либо класса, объекта или модуля, 
закрытая для доступа со стороны других классов, объектов и модулей, кроме тех, которые яв- 

protocol (протокол) — способ взаимодействия между объектами, отражающий их стати¬ 
ческие и динамические свойства а процессе такого взаимодействия. 

public (общедоступный) — часть интерфейса какого-либо класса, объекта или модуля, 
открытая для доступа всем другим классам, объектам и модулям. 

round-trip gestalt design (возвратное проектирование) — стиль проектирования, име¬ 
ющий дискретно-итеративный характер, с постепенным уточнением физической и логической 
картины системы. Объектно-ориентированное проектирование является возвратным, что подчер¬ 
кивает взаимное влияние целого и частного в системе. 

Selector (определитель состояния) — операция доступа к данным о состоянии объекта, 
не позволяющая изменять это состояние. 

Sequential object (объект-транслятор) — пассивный объект, имеющий единственный ка¬ 
нал управления. 

Server (исполнитель) — объект, управляемый другими объектами, но не используемый в 
качестве управляющего. 

Slot (слот) — фрагмент области данных из структуры объекта. Соответствует терминам 
«поле», «переменная объекта», «фрагмент объекта» (field, instance variable, member object). 

State (состояние) — один иа возможных вариантов условий существования объекта. 
Представляет собой текущий набор свойств объекта (обычно статических) и количественных 
значений этих свойств (динамических). 

State Space (пространство состояний) — перечислимое множество всех возможных состо¬ 
яний объекта. Пространство состояний программы содержит неопределенное или конечное число 
состояний (не обязательно желаемых или ожидаемых). 

State transition diagram (диаграмма перехода состояний) — фрагмент классификации, 
предназначенный для определения пространства состояний, допустимых для объектов данного 
класса; событий, вызывающих переходы из одного состояния в другое, и последствий изменений 
состояния. 

Static binding (статическая связь) — связь имени объекта (переменной) с классом. Ста¬ 
тическая связь устанавливается в процессе компиляции до создания объектов данного класса. 
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Фирма “ Диалектика ” готовит к выпуску в свет следующую 
литературу по программированию: 

- Turbo Vision для языка Pascal 

- Справочное руководство по FoxPro 2.0 в трех томах 
(совместное издание с АО ” И.В.К. ” ) 

- Программирование на C++ под Windows 
(совместное издание с АО ” И.В.К. ” ) 

- Turbo Pascal для Windows 

- Работа с библиотекой ObjectWindows 

ВНИМАНИЕ ! указанные книги будут издаваться малыми 
тиражами. 


Желающим приобрести данную литературу необходимо выслать 
заявку с указанием названия книги и количества экземпляров ( не 
забудьте указать обратный адрес ). Фирма “Диалектика” просит 
своих подписчиков сообщать интересующие Вас темы, а также указы¬ 
вать языки программирования и инструментальные средства, которые 
Вы используете. 

По мере издания книг, приславшие заявки будут уведомлены о 
способе приобретения литературы. 

Оптовым покупателям предоставляется скидка. 

Мы готовы рассмотреть любые ваши предложения. 

Звоните по тел. (044) 517-88-81 в г. Киеве. 

Заявки присылать по адресу : 

Украина, г.Киев ул.Пархоменко, 14 салон КОМТЕХ 
с грифом “Библиотека программиста” 










АННОТАЦИЯ: 


Одной из сложнейших задач, появляющихся при разработ¬ 
ке прикладных программ для WINDOWS , является упорядо¬ 
чение громадного числа обращений к интерфейсу прикладных 
программ среды WINDOWS (API). Эта задача значительно упро¬ 
щается при использовании разработанной фирмой BORLAND 
библиотеки ObjectWindows (OWL), однако для создания “по¬ 
слушных" прикладных программ, полностью соответствующих 
стандартам WINDOWS , необходимо знать как эти программы 
сочетаются, и как происходит вызов различных функций 
WINDOWS. 

Книга предназначена для программистов, чем объясняется 
большое количество листингов программ. Однако эта книга не 
просто набор листингов программ, так как в ней таакже подроб¬ 
но рассматриваются концепции и философия WINDOWS. 
Borland C++ дает Вам средства управления WINDOWS ; книга 
же даст Вам навыки эффективного использования э\их 
средств. Рассматривая библиотеку ObjectWindows, авторы 
наглядно демонстрируют, как быстро и эффективно можно 
создавать прикладные программы с использованием всех пре¬ 
доставляемых WINDOWS средств - текста, графики, меню, 
диалоговых окон и других. 

Несмотря на то, что большинство прикладных программ для 
WINDOWS сейчас пишутся на С , можно с уверенностью пред¬ 
сказать, что C++ скоро займет доминирующее положение. C++ 
дает возможность добавления объектного программирования к 
уже написаннм на С системам. Именно по этой причине была 
создана версия книги для C++. 

Эта книга написана для программистов, работающих с 
языком C++, с целью обучения программированию в среде 
WINDOWS. В книге приводятся тексты программ, дающие воз¬ 
можность более полного ознакомления с используемой систе¬ 
мой и ее возможностями. 



Книга состоит из шести частей. В первой части приводится 
краткая история WINDOWS , а также описываются три новых 
дополнения, с которыми сталкивается программист: создание 
программ, управляемых сообщениями, создание и управление 
графическим выводом, использование объектов пользователь¬ 
ского интерфейса. 

Во второй части рассматриваются проблемы, связанные с 
созданием минимальной для WINDOWS программы, а так же 
некоторые базовые положения программирования в среде 
WINDOWS . В этой части также рассматривается структура, 
общая для всех программ в WINDOWS. 

В третьей части описывается интерфейс графических уст¬ 
ройств (GDI). Этот интерфейс используется для создания аппа¬ 
ратно-независимого графического вывода. 

В четвертой части рассматриваются три ключевых объекта 
пользовательского интерфейса: меню, окна, диалоговые окна. В 
этой части описываются внутренние свойства каждого из объек¬ 
тов и основные способы их использования. 

Пятая часть посвящена средствам ввода. В этой части 
приводится подробное описание процесса ввода данных с фи¬ 
зического устройства через системные буфера в программу. 

В шестой части рассматриваются особенности операцион¬ 
ной системы. Эта часть включает два больших раздела: линко¬ 
вание в памяти и динамическое линкование. Одной из 
отличительной особенности версии WINDOWS 3.0 являются из¬ 
менения при использовании памяти. Для того, чтобы понять 
понять эти изменения, приводится подробное описание каждо¬ 
го из операционных режимов WINDOWS. 

Эта книга станет важной частью Ваших знаний о програм¬ 
мировании в среде WINDOWS. 

Принимаются заявки по адресу : Украина, г. Киев 

ул.Пархоменко, 14 салон КОМТЕХ с грифом “Библиотека 
программиста". Не забудьте вложить почтовую открытку с ука¬ 
занием названия книги, количества экземпляров и обратным 
адресом. 
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